Re: Real Time Runqueue

[Davide Libenzi]

On Fri, 16 Nov 2001, Mike Kravetz wrote:

> As you may know, a few of us are experimenting with multi-runqueue
> scheduler implementations.  One area of concern is where to place
> realtime tasks.  It has been my assumption, that POSIX RT semantics
> require a specific ordering of tasks such as SCHED_FIFO and SCHED_RR.
> To accommodate this ordering, I further believe that the simplest
> solution is to ensure that all realtime tasks reside on the same
> runqueue.  In our MQ scheduler we have a separate runqueue for all
> realtime tasks.  The problem is that maintaining a separate realtime
> runqueue is a pain and results in some fairly complex/ugly code.
>
> Since I'm not a realtime expert, I would like to ask if my assumption
> about strict ordering of RT tasks is accurate.  Also, is anyone aware
> of other ways to approach this problem?

I do not use a separate queue coz, if it's single, it becomes a common
lock for all CPUs.
RT tasks are scheduled as usual and the only problem arises in
reschedule_idle() when an RT task is pushed onto the run queue when
1) on its CPU it is _not_ running the idle
2) on its CPU is running another RT task with higher priority

In that case a "good CPU" discovery loop is triggered, the task is moved
on that CPU runqueue, need_resched is set, an IPI is sent and on return
from the remote CPU IPI  path the RT task is run.
A good solution would be ( i'm not doing it now ), in setscheduler() to
move the task in a way to have an even distribution of RT tasks among
CPUs.

- Davide