Messages in this thread | | | Date | Thu, 9 Dec 2004 10:02:50 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 |
| |
* K.R. Foley <kr@cybsft.com> wrote:
> [...] it looks to me like the whole scheduler is built on the premise > of allowing RT tasks to be just like other tasks with a few > exceptions, one of which is that RT tasks never hit the expired task > array.
this is more or less correct, and we are trying to keep RT scheduling 'integrated' into the SCHED_NORMAL scheduler as long as it's practical.
but Lee is correct too in that the scheduling behavior of RT tasks and SCHED_NORMAL tasks is completely different. But on the implementational level the distinction is less stark and boils down to a few branches here and there, while 90% of the scheduling code is shared.
to answer your question: it is true that if there is an RT task active then we never switch the arrays. That's how RT tasks work: they run until they want. That's why it needs privileges to use RT scheduling, and that's why a buggy RT task can lock up the system. The 'array switching' mechanism is part of the 10% of code that is only used by non-RT tasks. SCHED_FIFO tasks dont have any timeslices, they run until they deschedule voluntarily. SCHED_RR tasks have a notion of timeslices but they only yield to RR tasks on their own priority level, which is implemented without an array-switch. [the array-switch implements fair scheduling between different-priority SCHED_NORMAL tasks - this is a fundamentally harder problem which necessiates more work from the scheduler.]
(btw., the 'global RT balancing' SMP code i recently added, and the priority inheritance scheduler code increases the 10% of non-shared scheduling code to perhaps 15% or so. Not always is it possible to share code.)
Ingo - 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/
| |