Messages in this thread | | | Date | Fri, 16 Nov 2001 14:44:30 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: Real Time Runqueue |
| |
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
- 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/
| |