scx_rustland: improve interactive workloads #64
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 commit a7677fd ("scx_rustland: bypass user-space scheduler for short-lived kthreads") we were try to mitigate a problem that was actually introduced by using the wrong formula to evaluate weighted vruntime, see commit 2900b20 ("scx_rustland: evaluate the proper vruntime delta"). Reverting that (pseudo-)optimization doesn't seem to introduce any performance/latency regression and it makes the code more elegant, therefore drop it. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Avoid updating task information for tasks that are exiting, as they won't be used by the user-space scheduler. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The current implementation of the user-space scheduler is strongly prioritizing newly created tasks by setting their initial vruntime to (min_vruntime + 1); this prioritization places them ahead of other tasks waiting to run. While this approach is efficient for processing short-lived tasks, it makes the scheduler vulnerable to fork-bomb attacks and significantly penalizes interactive workloads (e.g., "foreground" applications), in particular in the presence of background applications that are spawning multiple tasks, such as parallel builds. Instead of prioritizing newly created tasks, do the opposite and account (max_slice_ns / 2) to their initial vruntime, to make sure they are not scheduled before the other tasks that are already waiting for the CPU in the current scheduler run. This allows to mitigate potential fork-bomb attacks and it strongly improves the responsiveness of interactive applications (such as UI, audio/video streams, gaming, etc.). With this change applied, under certain conditions, scx_rustland can even outperform the default Linux scheduler. For example, with a parallel kernel build (make -j32) running in the background, I can play Terraria with a constant rate of ~30-40 fps, while the default Linux scheduler can handle only ~20-30 fps under the same conditions. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
arighi
force-pushed
the
improve-interactive-workloads
branch
from
a560e3f
to
5d9182d
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.
Big logical change:
Small "cleanup" changes:
The big change can actually make scx_rustland relevant under certain conditions. As I mentioned in the commit message:
While the scheduler isn't quite production-ready, I think we're approaching a state where it can be considered "usable" (under certain conditions) and someone might even find it beneficial in a few real-world scenarios (also considering how easy it is to extend its functionality, by simply modifying the Rust part).