4 ms·
> For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain
by amluto 3y ago
> For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain cost.
Aside from possibly increased scheduler latency, there’s the rather larger potential cost of outright deadlocks: what guarantees that the user scheduler task runs at all when it’s needed?
On 60 seconds of skimming the repo, I didn’t spot a specific solution to this problem. I wonder how it was addressed. Or maybe it wasn’t, since this is just an experiment.
- loeg 3y agoAt least in one version of the documentation patch, there's mention of a watchdog timeout that unloads the user scheduler if it fails to make forward progress for some period of time. https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/02300.html https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/0...
- manifault 3y agoCorrect -- the purpose of the watchdog is to account for buggy schedulers that fail to schedule runnable tasks. scx_rustland has special logic to track the user-space scheduling task, though. If it incorrectly failed to schedule it when it had no more runnable tasks to run, then the watchdog would eventually kick in, boot out scx_rustland, and revert back to EEVDF.
- manifault 3y agoThe scx_userland scheduler itself knows which task in user space is the scheduler task, and schedules it when it doesn't have any more runnable tasks to dispatch from the kernel: https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_rustland/src/bpf/main.bpf.c#L450-L468 https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_r...
- amluto 3y agoHah, I should have spent 120 seconds searching :)