Skip to content
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

scx_rustland: interactive tuning #181

Merged
merged 2 commits into from
Mar 10, 2024
Merged

scx_rustland: interactive tuning #181

merged 2 commits into from
Mar 10, 2024

Conversation

arighi
Copy link
Contributor

@arighi arighi commented Mar 10, 2024

A couple of adjustments that have been empirically proven to be highly effective in improving system responsiveness, particularly in the context of gaming and live conferencing / live streaming workloads.

Reducing the base time slice from 20ms to 5ms helps prevent potential audio cracking issues and sporadic lags under average load conditions. Additionally, setting a cap on the maximum task weight helps prevent similar issues when tasks with very high priority are running within the same SCHED_EXT scheduling class.

Andrea Righi added 2 commits March 10, 2024 14:39
Some high-priority tasks may have a weight too high, that can
potentially disrupt the slice boost optimization logic, causing
interactive tasks to be less responsive.

In line with rustland's focus on prioritizing interactive tasks, prevent
giving too much CPU bandwidth to such high-priority tasks by limiting
the maximum task weight to 1000.

This allows to maintain a good level of system responsiveness even in
presence of tasks with a really high priority.

Signed-off-by: Andrea Righi <[email protected]>
In line with rustland's focus on prioritizing interactive tasks, set the
default base time slice to 5ms.

This allows to mitigate potential audio craking issues or system lags
when the system is overloaded or under memory pressure condition (i.e.,
#96 (comment)).

A downside of this change is to introduce potential regressions in the
throughput of CPU-intensive workloads, but in such scenarios rustland
may not be the optimal choice and alternative schedulers may be
preferred.

Signed-off-by: Andrea Righi <[email protected]>
@arighi arighi merged commit b7c06b9 into main Mar 10, 2024
1 check passed
@Byte-Lab Byte-Lab deleted the rustland-interactive-tuning branch March 14, 2024 18:19
@Byte-Lab Byte-Lab restored the rustland-interactive-tuning branch March 14, 2024 18:19
@Byte-Lab Byte-Lab deleted the rustland-interactive-tuning branch March 14, 2024 18:20
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