Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 | From | Steven Rostedt <> | Date | Tue, 14 Dec 2004 08:01:36 -0500 |
| |
On Mon, 2004-12-13 at 18:45 -0500, john cooper wrote: > Steven Rostedt wrote: > > > > 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). > > My point was the server thread in the above scenario is > non-preemptable. Otherwise upon B soliciting service from > S, A's work by S would be preempted and attention would be > given immediately to B. >
Why must the server be non-preemptable? Have you written code for a server that can immediately switch to another clients request? I've tried, and it's not easy. The work of the server would only process one client at a time. In that regard, the server is "non-preemptable", but in services to be done, not in context switching. B would preempt server S just because B is a higher priority. But when B puts itself to sleep on S's wait queue, S would then inherit B's priority. But S would still be finishing A's work. When S finished A's work, it would go directly on to B's work. This is just like a mutex. Think of the code within a mutex as a service, and the Server is just the thread that happens to be doing the work. So Process A would go into the mutex, become Sa, then when B wanted to go into the mutex, Sa would inherit B's priority, and when it's finish with A's work, it would become Sb.
> This may very well be a concession to simplicity in the > design. The server context on behalf of client A would need > to be saved [somewhere] when B caused the preemption and > restored when A's priority deemed doing so. > Server S would not know that B is on the wait queue, except that B has increased S's priority. S would still work on A's request, so the only saving for S would be in the S's stack when B preempted it.
> For a mutex, the priority promotion of 'anything of lower > priority in my way' to logical completion is needed to > preserve the semantics of a mutex, ie: mutex ownership cannot > be preempted. However in general this doesn't hold for the > server thread model. We could redirect the server > immediately to a different client at the cost of additional > context switching -- a compromise to consider. >
How would you redirect the Server? If server S is working on A's work, (let's make it easy and use the example of a web server) A sends S a request to serve page P, S goes to retrieve P, then B comes along and request page Q, how would you write the code to know to stop working on getting P and start getting Q, S is a single thread, doing the work, not multiple instances.
> Again this is the general case. It is likely for critical > sections to exist in the server thread where preemption must > be disabled analogous to the kernel/cpu preemption model. > > > ...The work to keep track of what priorities are being > > inherited is even easier than mutexs... > > The dependency chain does exist here as for mutexes if we > allow servers to wait on other servers. Note in this usage > a preemptive server model favors preemption over priority > propagation unless the target server is itself blocked. >
If you have a single thread working as the server, how do you go about writing code that can have that thread stop a task in the middle and start doing something else. Although there may not be a need to do certain things non-preemptively, but a server (should I say server thread), only does one task at a time, giving it a same functionality as a mutex.
> Note here it is more obvious [at least to me] circular > dependencies are to be disallowed. With mutexes, especially > of the reader/writer variety, circular ownership > dependencies can go unnoticed which will confound the > priority promotion logic. >
I agree with you here, since a process can only have one server working on it at a time. But this can become a problem, if you have one server working for another server. If server S needs something from server X then X needs something from server S, and they both are waiting. But that would already have shown up in the kernel.
The whole point I'm trying to make is that today, when a high priority process goes onto a wait queue, the process that will server that rt process may be of a lower priority than other processes lower that the original rt process that is waiting. So you have a case of priority inversion within processes serving other processes.
-- 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/
| |