Post a Comment
The link to "University of Copenhagen" is actually a link to the department of computer science at the university.
Why do we need yet another schedular implementation?
Not knocking the effort these people have put in, but kernel options can be confussing at the best of times... now we are going to be spoilt for choice in schedulars.
..this is sort of a "plug-n-play" interface for schedulers? Hmmm. Interesting I guess. I know very little about the linux kernel, so I shouldn't even comment, but how does the kernel continue to interface with process loaders (memory swapping, etc)? Or does it really simply manage a list of processes (not swapped out I guess) based on some algorithm you hand it, communicating with a loader to pull the process into execution when its turn is ready?
Heh. I am confusing myself now.
Mike
very nice work! I love abstraction. And this is just an area one can use such abstraction.
Very nice article as well. I'd love to go play with this if only I had the time... ;-)
Joop
..this is sort of a "plug-n-play" interface for schedulers? Hmmm. Interesting I guess. I know very little about the linux kernel, so I shouldn't even comment, but how does the kernel continue to interface with process loaders (memory swapping, etc)? Or does it really simply manage a list of processes (not swapped out I guess) based on some algorithm you hand it, communicating with a loader to pull the process into execution when its turn is ready?
Heh. I am confusing myself now.
Mike
========
RESPONSE
========
The scheduler is seperate from the memory management. The scheduler is responsible for picking which process will be run next. It does not matter if the program is currently in memory or not. The scheduler most likely looks at the process table for a list of potential processes to run.
Gotcha! It's a pick-list with smarts. But more, since it is the core of kernel really, no? It's more like a director than a pick-list. Abstracting it then provides a consistent interface for any kernel implementing it.
Why do we need more scheduler options? Because there's more than one way to do things. Have a look at this paper on Lottery Scheduling for an interesting concept:
http://www-csag.ucsd.edu/teaching/cse225s04/Reading%20List/lott...
Whatever makes it easier to experiment and try out new ideas is welcomed by me.
allowing an administrator to adjust or alternate scheduling algorithms during run-time would be very useful. this remove the need to boot different kernels or even OSes depending on your current workload.
This should be 'defensively' patented. After sucessful patenting, transfer all rights to the Free Software Foundation. We'll ammase our own patent portfolio.
I also think that we'll see more more of this, in the VM and Caching sections of code.
i just read the article properly ... what an excellent article!
thanks.
if you try the RR scheduler test and have difficulties or whatever, you may get feedback on the ml of Bossa: bossa@emn.fr (i forgot to link it)
I've finally learned what a scheduler is
By the way, the link to the "The Bossa version of the EDF policy" at the end of the article doesn't work for me, and in the fourth step of the fourth page, where it states "The source code can be found in loop10.c et loop30.c" it should be "and", not "et" 



