Hacker News Reader

Comment by jandrese | Hacker News Reader

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.

View on HN

> 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 :/

> in case of bugs the user-space scheduler will just crash and sched-ext will transparently restore the default Linux scheduler.

You 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.

Well, GNU Hurd would survive to that right?

Happens 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.'

Aren't those schedulers working only on their own processes though? If they screw up it doesn't blow up the rest of the system.

If everything useful a system does is in this process, then what's the difference?

You 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.

Reply on news.ycombinator.com