scx_rustland: dynamic time slice #73
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
htejun
approved these changes
Jan 8, 2024
scheds/rust/scx_rustland/src/bpf.rs
Outdated
| // Get current value of time slice (slice_ns). | ||
| #[allow(dead_code)] | ||
| pub fn get_slice_us(&mut self) -> u64 { | ||
| let slice_ns = self.skel.bss().sched_slice_ns; |
There was a problem hiding this comment.
The naming is confusing. Maybe dynamic_slice_ns or effective_slice_ns would be better?
There was a problem hiding this comment.
I like effective_slice_ns, it's a lot more clear, I'll go with that. Thanks!
Add to BpfScheduler() the new methods set_effective_slice_us() and get_effective_slice_us(). These methods can be used by the user-space scheduler to dynamically adjust (and retrieve) the effective time slice used to dispatch tasks within the BPF dispatcher. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Implement a simple logic in the user-space scheduler to automatically adjust the tasks' time slice: reduce the time slice by a scaling factor of (nr_waiting / nr_cpus + 1), where nr_waiting is the amount of tasks waiting in the scheduler and nr_cpus is the amount of CPUs in the system. Using a fine-grained time slice as the number of tasks in the system grows, improves responsiveness of low-latency activities (e.g., audio, video games), also in presence of other CPU-intensive tasks that are concurrently running in the system. On the other hand, extending the time slice when only a limited number of tasks are active in the system contributes to an enhancement in the overall system throughput and a reduced amount of context switches. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
With the introduction of a variable time slice that scales down in function of the amount of waiting tasks, the scheduler is able to handle a steady stream of newly spawned tasks, without having to de-prioritize them to guarantee a good level of system responsiveness. Hence, the logic for de-prioritizing new tasks can be removed, as it currently doesn't provide any measurable benefits. In fact, it even proves counterproductive as it can implicitly slow down the interactive performance of shell sessions when the system is overloaded with a significant amount of CPU hogs (e.g, `stress-ng -c 128`). Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
arighi
force-pushed
the
scx-rustland-dynamic-timeslice
branch
from
79cb7a1
to
fa6915c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Provide a new abstraction for the user-space scheduler to dynamically adjust the time slice used to dispatch tasks. Moreover, implement a mechanism in the user-space scheduler to dynamically scale the time slice as a function of the waiting tasks and the available CPUs in the system.
Apart for the benefits of having an additional scheduling abstraction (that can be beneficial for potential developers interested in expanding RustLand), this change also significantly improves the interactive performance of the scheduler, especially when the system is overloaded by a massive amount of CPU hogs (e.g.,
stress-ng -c 256).Before this change the stress-ng command above could make my system pretty much unresponsive (triggering the sched-ext watchdog / stall detector). With this change applied the scheduler survives and I'm still able to run commands.