5 ms·
Of all the things a you can run in userspace, the scheduler is the one that I never thought would happen. I guess the scheduler has to give itself time to run
by jandrese 3y ago
Of all the things a you can run in userspace, the scheduler is the one that I never thought would happen. I guess the scheduler has to give itself time to run in userspace? It seems like there would be a chicken and egg problem at boot time before userspace is brought up. Would be pretty embarrassing if your scheduler got killed by a OOM or something.
- anthk 3y agoWell, GNU Hurd would survive to that right?
- deleted 3y ago[deleted]
- kccqzy 3y agoYou could make the kernel treat the scheduler specially (just like today it already treats PID 1 specially) by always making the scheduler run whenever the kernel doesn't know what to run next.
- wyldfire 3y ago> Would be pretty embarrassing if your scheduler got killed by a OOM or something. Or if you starved your scheduler process because it wasn't high enough priority :/
- thewakalix 3y ago> in case of bugs the user-space scheduler will just crash and sched-ext will transparently restore the default Linux scheduler.
- lstodd 3y agoHappens all the time with the userspace async stuff, swapcontext(3), freebsd n:m threads, greenthreads, stackless py, it's all ancient, and they're all userspace schedulers. I think SA takes it a bit too far though. Even if it looks like a 'logical progression of them older ideas.'
- Vecr 3y agoYou memlock everything, so OOM's not a problem, per se. You need to allocate a bunch up front though. If your program does not handle allocations failing it'll panic (Rust term) and switch back to the kernel's normal scheduler.