scx_rustland: lowlatency improvements #59
Conversation
Make sure the scheduler is not activated if we are deadling with the last task running. This allows to consistency reduce scx_rustland CPU usage in systems that are mostly idle (and avoid unnecessary power consumption). Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Use dispatch_on_cpu() when possible, so that all tasks dispatched by the user-space scheduler gets the same priority, instead of having some of them dispatched to the global DSQ and others dispatched to the per-CPU DSQ. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Bypass the user-space scheduler for kthreads that still have more than half of their runtime budget. As they are likely to release the CPU soon, granting them a substantial priority boost can enhance the overall system performance. In the event that one of these kthreads turns into a CPU hog, it will deplete its runtime budget and therefore it will be scheduled like any other normal task through the user-space scheduler. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
In the scheduler statistics reported periodically to stdout, instead of showing "pid=0" for the CPU where the scheduler is running (like an idle CPU), show "[self]". This helps to identify exactly where the user-space scheduler is running (when and where it migrates, etc.). Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
| * No scheduling required if it's the last task running. | ||
| */ | ||
| if (enq_flags & SCX_ENQ_LAST) | ||
| return true; |
There was a problem hiding this comment.
I don't quite understand what difference this commit makes given that the default behavior w/o SCX_ENQ_LAST is auto-enq on local dsq. Does this make any behavior difference?
There was a problem hiding this comment.
I don't quite understand what difference this commit makes given that the default behavior w/o SCX_ENQ_LAST is auto-enq on local dsq. Does this make any behavior difference?
For some reasons with this in place the CPU utilization of scx_rustland drops significantly when the system is idle (like 0.3-0.5%), without this change when the system is idle I can see some cpu usage spikes of up to 5-10%,but I'm not sure why it's happening... My theory was that with SCX_ENQ_LAST in place we could save some unnecessary usersched invocations.
There was a problem hiding this comment.
That's surprising given that the two essentially are doing the same thing. Maybe there's something timing dependent going on or I'm just confused.
There was a problem hiding this comment.
That's surprising given that the two essentially are doing the same thing. Maybe there's something timing dependent going on or I'm just confused.
I'll run some tests with and without that and collect more info, now I want to understand what's going on exactly :)
There was a problem hiding this comment.
@htejun it's SCX_OPS_ENQ_LAST set in sched_ext_ops.flags that seems to make a difference, the check in is_task_cpu_available() does't make any difference and can be dropped apparently.
Low-latency improvements:
Reduce user-space overhead:
UI improvement: