On Thu, Jan 20 2005, [EMAIL PROTECTED] wrote: > On Thu, 20 Jan 2005 11:14:48 EST, "Marc E. Fiuczynski" said: > > Peter, thank you for maintaining Con's plugsched code in light of Linus' and > > Ingo's prior objections to this idea. On the one hand, I partially agree > > with Linus&Ingo's prior views that when there is only one scheduler that the > > rest of the world + dog will focus on making it better. On the other hand, > > having a clean framework that lets developers in a clean way plug in new > > schedulers is quite useful. > > > > Linus & Ingo, it would be good to have an indepth discussion on this topic. > > I'd argue that the Linux kernel NEEDS a clean pluggable scheduling > > framework. > > Is this something that would benefit from several trips around the -mm > series? > > ISTR that we started with one disk elevator, and now we have 3 or 4 > that are selectable on the fly after some banging around in -mm. (And > yes, I realize that the only reason we can change the elevator on the > fly is because it can switch from the current to the 'stupid FIFO > none' elevator and thence to the new one, which wouldn't really work > for the CPU scheduler....)
I don't think you can compare the two. Yes they are both schedulers, but that's about where the 'similarity' stops. The CPU scheduler must be really fast, overhead must be kept to a minimum. For a disk scheduler, we can affort to burn cpu cycles to increase the io performance. The extra abstraction required to fully modularize the cpu scheduler would come at a non-zero cost as well, but I bet it would have a larger impact there. I doubt you could measure the difference in the disk scheduler. There are vast differences between io storage devices, that is why we have different io schedulers. I made those modular so that the desktop user didn't have to incur the cost of having 4 schedulers when he only really needs one. > All the arguments that support having more than one elevator apply > equally well to the CPU scheduler.... Not at all, imho. It's two completely different problems. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
