Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Steven Rostedt]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/