scx_rustland: time slice boost #81
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
With the introduction of a the dynamic time slice that scales down based on the number of tasks in the system, there is no obvious benefit in utilizing SCX_ENQ_PREEMPT to dispatch the user-space scheduler. The reduced time slice as the task count increases already enhances the user-space scheduler's opportunities to run and efficiently manage scheduling tasks, even when the system is massively overloaded. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Introduce a parameter to prioritize active running tasks over newly created tasks. This option can be used to enhance interactive applications (e.g., games, audio/video, GUIs, etc.) that are concurrently running with fork-intensive background workloads (such as a large parallel build for example). The boost value (which functions as a penalty) is applied to the time slice attributed to newly generated tasks, increasing their vruntime and, in an indirect manner, "boosting" the priority of all the other concurrent active tasks. The time slice boost parameter was applied in the live demo video [1] to enhance the frames per second (fps) of a video game (Terraria), running simultaneously with a parallel kernel build (`make -j 32`) on an 8-core laptop (the value used in the video matches the existing setting of running `scx_rustland -b 200`). [1] https://www.youtube.com/watch?v=oCfVbz9jvVQ Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
htejun
approved these changes
Jan 10, 2024
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.
This PR includes the "time slice boost" option (that should be called "time slice penalty", but boost sounds more cool 馃槈), that is the extra patch that I've used for live demo video (https://www.youtube.com/watch?v=oCfVbz9jvVQ), cleaned up a little bit.
I was a bit skeptical to send this one, because it can make the scheduler more unpredictable / unstable if used improperly, but at the end the worst case scenario would be a 5s stall, before the sched-ext watchdog kicks out the scheduler and the benefit can be that people may actually want to test and play around with this.
Moreover, without using
-b NUM, no boosting is applied, so the default behavior remains unchanged.In addition to that there's also a small patch to dispatch the user-space scheduler without SCX_ENQ_PREEMPT, that is not really needed anymore at this point.