Con Kolivas posted a set of patches to the lkml offering a pluggable cpu scheduler framework. The architecture independent framework is designed to allow new schedulers to be added by only touching three files, without adding overhead, and allowing you to compile in only the CPU scheduler(s) you need.
Linux: Pluggable CPU Schedulers
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
is this at all a set towards possibly making linux a microkernel
No. The schedulers still run in kernel space, it’s just possible to select at compile-time which scheduler you want to use. That’s helpful, because different schedulers are good for different workloads. The same thing is true of I/O schedulers in Linux now, too.
From a programming point of view, this is a good thing. Seperating the mechanism of scheduling from the scheduling policy is good design.
Howdy
It seems like there will finally be a good debate over whether special purpose schedulers will ever get the proper support they deserve in the main kernel or if they will continue to select a general purpose and stretch it to include all the corner cases that people seem to come up with.
Both have good points but honestly with the current scheduler just have a look at the magic they have put into it and the amount of code something like the staircase scheduler removes to see why IMHO mking this modular is the right way to go.
I have been thinking of the possibility to be able to select scheduler at boot time – very much in the same way you can select which mode the Java VM will run in by selecting “client” or “server”. Just passing an argument on the kernel commandline – “server”, “client”, “mysched1”, “mysched2” etc.
Wouldn’t that be handy?
Ive played around with different schedulers and read some of the documentation, but does anyone know(or have a link to) a list of all the current schedulers(like the standard shipped set and the ones in different – branches) and what they do, and what workloads they handle best? I think such a resource(like a chart or table) could be very useful.
The only thing I know about the issue is that without the ck patchset the desktop user experience in Linux really sucks. The first time I compiled a kernel with ck patches I just couldn’t believe such an improvement was possible.
cheers
I’d love to see a 64-Bit Linux with an *exokernel* at its base.
Leave only security to the kernel, move the rest to user space.
–EyeAm
http://s87767106.onlinehome.us
linux has always bucked some of the “good design” appraoches of the academic. but in the end it seemed ot benefit from the “perform now, design later” idea.
more recently it has settled down and decided to look a itself again .. and redesign itself .. and the modular appraoch seems good.
ingo’s concerns that one very well designed schedular is better than many specific schedulers which may not handle unforseen loads is not that convincving – you can demote his great all-purpose schedular to one of the optional “modules”. no?
personally i think it is possible to switch at runtime, using sometijng like /proc … and even to gather statistocs from /proc/schedulars … maybe even go the whole hog and take the likes of other OSes and group processes/tasks to be handled by different schedulars (that is a grand schedular deivides cpu time, sub-schedulars work within that to schedule classes of process/threads/task – not new – threading was supposed to havre this in threads groups but i t was abandonded i think, realtime patches to linux do this – with the RT schedular yielding to the non-RT tasks).
and whata bout BSD? netbsd? freebsd?
can anyone compare briefly their scheduling strategies. myself i don’t “feel” better interactivity. which is better for “mixed loads” (throughput as wll as interactivity) – my feeling is the bsds – my mandrake 10 doesn’t like mixed loads!
Im not sure but I seem to recall before he died, Manuel Estrada Sainz was working on something that did basically what you want. It compared the different algorithms used in Operating Systems and how they performed compared to each other.
I think his concern is not so much a matter of technology, but social engineering. Even if a uber CPU scheduler is technically possible under the pluggable scheme, that doesn’t change the fact that the social constraints under the pluggable model discourage such a scheduler. I can kinda see both sides of the argument — I hope there are other social constraints that can be imposed to encourge development on a single good scheduler, without getting rid of the pluggable model, which is needed in some edge cases.
Last i checked with Con it DID have a boot option for it
-DaMouse