Messages in this thread | | | Date | Tue, 30 Oct 2001 11:08:06 -0800 | From | Mike Kravetz <> | Subject | Re: [Lse-tech] Re: [PATCH][RFC] Proposal For A More Scalable Scheduler ... |
| |
On Tue, Oct 30, 2001 at 11:52:57AM -0500, Hubertus Franke wrote: > * Davide Libenzi <davidel@xmailserver.org> [20011030 13;50]:" > > On Tue, 30 Oct 2001, Hubertus Franke wrote: > > > > > There is however another problem that you haven't addressed yet, which > > > is realtime. As far as I can tell, the realtime semantics require a > > > strict ordering with respect to each other and their priorities. > > > General approach can be either to limit all RT processes to a single CPU > > > or, as we have done, declare a global RT runqueue. > > > > Real time processes, when wakeup up fall calling reschedule_idle() that > > will either find the CPU idle or will be reschedule due a favorable > > preemption_goodness(). > > One of balancing scheme I'm using tries to distribute RT tasks evenly on > > CPUs. > > > > I think that would be a problem. My understanding is that if two RT process > are globally runnable, then one must run the one with higher priority. > Am I missing something here ?
It is not just the relative priorities of the realtime tasks, but also the scheduling policy. SCHED_FIFO (and to some extent SCHED_RR) implies an ordering within the runqueue for tasks of the same priority. This is difficult to achieve with multiple runqueues. Most scheduler implementations I am aware of, do something like what you suggested above.
-- Mike - 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/
| |