3 ms·
Kernel support for green threads (or better, M:N) was a big topic 20 years ago. Look for "scheduler activation" for example. It kind of petered off as kernel o
by gpderetta 4y ago
Kernel support for green threads (or better, M:N) was a big topic 20 years ago. Look for "scheduler activation" for example.
It kind of petered off as kernel only threads were fast enough with significantly less complexity. In might be worth revisiting again.
- smasher164 4y agoYeah, scheduler activations were one approach, albeit one that wasn't deemed effective. I think FreeBSD ended up removing the feature. A more recent attempt that's interesting is ghOSt from Google: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/0ee589331b9bf270b13d40ba09453cde14006869.pdf https://storage.googleapis.com/pub-tools-public-publication-....
- tedunangst 4y agoThe problem solved by SA is equivalently solved by a scalable multiplex IO syscall like kevent and userland scheduling. There's no particular need for the upcall if blocking information is available another way. I think it's dead.
- gpderetta 4y agoYou might want to preempt after scheduling quanta expirations, page faults, etc. And there is still the issue of existing code that use the standard blocking system APIs. Also a synchronous API can be more efficient if it is not going to block and only the kernel can know. In practice you are right, so far SA hasn't been worth the complexity.