Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 | From | Steven Rostedt <> | Date | Sat, 11 Dec 2004 23:36:31 -0500 |
| |
On Sat, 2004-12-11 at 11:59 -0500, john cooper wrote: > Steven Rostedt wrote: > > > [RFC] Has there been previously any thought of adding priority > > inheriting wait queues. With the IRQs that run as threads, have hooks in > > the code that allows a driver or socket layer to attach a thread to a > > wait queue, and when a RT priority task waits on the queue, a function > > is call to increase (if needed) the priority of the attached thread. I > > know that this would take some work, and would make the normal kernel > > and RT diverge more, but it would really help to solve the problem of a > > high priority process waiting for an interrupt that can be starved by > > other high priority processes. > > I think there are two issues here. One being as above which > addresses allowing the server thread to compete for CPU time > at a priority equal to its highest waiting client. Essentially > the server needs no inherent priority of its own, rather its > priority is automatically inherited. The semantics seem > straightforward even in the general case of servers themselves > becoming clients of other servers. >
I agree with you on this.
> Another issue is the fact the server thread is effectively > non-preemptive. Otherwise a newly arrived waiter of priority > higher than a client currently being serviced would receive > immediate attention. One problem to be solved here is how to > save/restore client context when a "context switch" is required.
I don't quite understand your point here.
Say you have process A at prio 20 that waits on a queue with server S. S becomes prio 20 and starts to run. Then it is preempted by process B at prio 30 which then comes to wait on the server's queue. Server S becomes prio 30 and finishes process A's work, then checks the queue again and finds process B and starts working on process B's work still at prio 30. The time of process B is still bounded (predictable).
So it's similar to a mutex and priority inheritance. We can look at process A taking lock L and then when process B blocks on lock L, process A inherits process B's priority (B being greater prio than A). The difference is that the work is being done within a mutex as suppose to a server. The work to keep track of what priorities are being inherited is even easier than mutexs, since you have a process (the server) to just point to which process it has inherited, and a wait queue to store which process needs to be inherited next when the server wakes up the currently inherited process.
-- Steve
- 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/
| |