Messages in this thread | | | Date | Wed, 26 Jul 2006 15:14:02 +1000 | From | Peter Williams <> | Subject | Re: [ANNOUNCE][RFC] PlugSched-6.4 for 2.6.18-rc2 |
| |
Al Boldi wrote: > Peter Williams wrote: >> Al Boldi wrote: >>> Peter Williams wrote: >>>> Al Boldi wrote: >>>>> Peter Williams wrote: >>>>>> Al Boldi wrote: >> [bits deleted] >> >>>>>>> It may be really great, to allow schedulers perPid parent, thus >>>>>>> allowing the stacking of different scheduler semantics. This could >>>>>>> aid flexibility a lot. >>>>>> I'm don't understand what you mean here. Could you elaborate? >>>>> i.e: Boot the kernel with spa_no_frills, then start X with spa_ws. >>>> It's probably not a good idea to have different schedulers managing the >>>> same resource. The way to do different scheduling per process is to >>>> use the scheduling policy mechanism i.e. SCHED_FIFO, SCHED_RR, etc. >>>> (possibly extended) within each scheduler. On the other hand, on an >>>> SMP system, having a different scheduler on each run queue (or sub set >>>> of queues) might be interesting :-). >>> What's wrong with multiple run-queues on UP? >> A really high likelihood of starvation of some tasks. > > Maybe you are thinking of running independent run-queues, in which case it > would probably be unwise to run multiple RQs on a single CPU.
No. I'm thinking about different schedulers on a single run queue. I don't think that it's a good idea.
> > But I was more thinking of a run-queue of run-queues, with the masterRQ > scheduling slaveRQs, each RQ possible running its own scheduling semantic.
I think that you need to think a bit harder about the consequences of such a system. The word "chaos" springs to mind.
Peter -- Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |