Skip to content

chaos: guarantee dispatch of tasks on quiet cpus #1622

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 3, 2025

Conversation

JakeHillion
Copy link
Contributor

scx_chaos uses dispatch to perform delayed enqueue of tasks. If dispatch doesn't
run for an arbitrarily long time, these tasks sit in the queue. This doesn't
appear to cause stalls on a system where all CPUs are online, but it does mean
the tasks get delayed for a long time, particularly when the CPU goes idle.

Add a timer that walks each per-CPU delay queue and kicks the CPU if the task is
due an enqueue. Use a slack factor to kick the CPU gently for a couple of milliseconds,
then preempt if the queue still hasn't been dealt with.

The numbers for this timer probably need tuning on smaller systems, but leaving
them hardcoded for now. They're const volatiles so easy to add CLI args for in
the future.

Drive by:

  • Correct random_delays_{min,max}_ns from u32->u64.
  • Add a macro for the number of tasks dealt with in dispatch and fix off by one error.

Test plan:

  • Ran sudo target/release/scx_chaos --random-delay-frequency 0.1 --random-delay-max-us 500000 --random-delay-min-us 500000.
    System feels much more responsive than before.

@JakeHillion JakeHillion requested review from htejun and hodgesds April 3, 2025 14:27
scx_chaos uses dispatch to perform delayed enqueue of tasks. If dispatch doesn't
run for an arbitrarily long time, these tasks sit in the queue. This doesn't
appear to cause stalls on a system where all CPUs are online, but it does mean
the tasks get delayed for a long time, particularly when the CPU goes idle.

Add a timer that walks each per-CPU delay queue and kicks the CPU if the task is
due an enqueue. Use a slack factor to kick the CPU gently for a couple of milliseconds,
then preempt if the queue still hasn't been dealt with.

The numbers for this timer probably need tuning on smaller systems, but leaving
them hardcoded for now. They're const volatiles so easy to add CLI args for in
the future.

Drive by:
- Correct random_delays_{min,max}_ns from u32->u64.
- Add a macro for the number of tasks dealt with in dispatch and fix off by one error.

Test plan:
- Ran `sudo target/release/scx_chaos --random-delay-frequency 0.1 --random-delay-max-us 500000 --random-delay-min-us 500000`.
  System feels much more responsive than before.
@JakeHillion JakeHillion added this pull request to the merge queue Apr 3, 2025
Merged via the queue into sched-ext:main with commit cfb0a78 Apr 3, 2025
30 checks passed
@JakeHillion JakeHillion deleted the pr1622 branch April 3, 2025 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants