GhOSt: Fast and Flexible User-Space Delegation of Linux Scheduling(dl.acm.org)
dl.acm.org
GhOSt: Fast and Flexible User-Space Delegation of Linux Scheduling
https://dl.acm.org/doi/10.1145/3477132.3483542
8 comments
This is pretty cool! If I'm understanding this correctly, this would make it possible for green thread implementations to call FFI code with low-overhead? What are the plans to upstream this?
There’s actually a different patch set that may help there:
https://lwn.net/Articles/863386/
Not sure if it's quite the same, but also see https://docs.microsoft.com/en-us/windows/win32/procthread/us...
@pron Could their be some kind of synergy between GhOSt and Project Loom?
(Java's upcoming structured concurrency.)
(Java's upcoming structured concurrency.)
The danger of user space scheduling: proprietary implementations of scheduling algorithms. Given enough time, instead of a huge effort for a scheduler that has few tunables and works reasonably well for most cases, we'll get a lot of proprietary schedulers that works very well but each for a single very specialized case. The end result maybe the out-of-the-box scheduler becomes neglected and mostly abandoned in the future.
I don't think that the vanilla scheduler would get abandoned, instead, it would then acts as a fallback scheduler when customized userspace scheduler crashed or getting an update and so on.
Well you can already do whatever proprietary stuff you want with your own kernels if you're not putting them on devices that you sell to people. In practice, this means that Amazon, Google, etc likely have pretty fancy, totally unshared scheduler changes that are worth a significant amount of money. [0]
As for the risk of selling something with proprietary scheduler bits, the upshot is that this is well handled, because most of the interfaces are GPL-only. IANAL, but this [1] is probably an interesting read.
[0] btw, more often than not the reason that these things don't go upstream is because upstream says "no." Even if such changes are worth a lot of money to the business, it's not enough that the competitive advantage outweighs the maintenance cost of a forked scheduler
[1] https://lore.kernel.org/netdev/20210916032104.35822-1-alexei...
As for the risk of selling something with proprietary scheduler bits, the upshot is that this is well handled, because most of the interfaces are GPL-only. IANAL, but this [1] is probably an interesting read.
[0] btw, more often than not the reason that these things don't go upstream is because upstream says "no." Even if such changes are worth a lot of money to the business, it's not enough that the competitive advantage outweighs the maintenance cost of a forked scheduler
[1] https://lore.kernel.org/netdev/20210916032104.35822-1-alexei...
Or you could see the opposite. Extra complexity for edge cases in the default scheduler can be rejected if there is a reasonable alternative. Quality for the main cases can improve.