Inside the Linux scheduler

[Dmitri Nikulin]

That Linux is replacing its scheduler, threading facilities, VM,
Filesystem of Choice, etc. several times per branch, often at a cost
to module compatibility, is a pretty clear reason to use it as a
counter-example of kernel development. I don't even suppose Linux is a
competitor - DragonFly is for clustering and Linux is completely
broken there, and Linux is for 'everything' (jack of all trades) and
short of a huge influx of developer and user resources DragonFly will
never, ever catch up in that field, and if it does, it'd probably hurt
the goals of the project anyway.
Not to say a better scheduler isn't welcome, but it should be positive
towards the goals of DragonFly, not to emulate the behavior of Linux,
bugs-n-all.
For instance, that documentation mentions that the CPU load balancer
willingly under-utilizes CPU caches, which is a great way to kill
throughput. Matt has gone to great lengths to educate his mailing list
and documentation readers why it's worth saving every cycle and
avoiding every cache miss, so deliberately scheduling in the opposite
way is probably not a scheduler DragonFly wants to end up with.
---
Dmitri Nikulin
Centre for Synchrotron Science
Monash University
Victoria 3800, Australia
email: dnikulin at xxxxxxxxx