Re: RT patch acceptance

[Esben Nielsen <simlo@phys.au.dk>]

On Tue, 31 May 2005, Andrea Arcangeli wrote:

> On Tue, May 31, 2005 at 06:48:50AM -0400, James Bruce wrote:
> > orthogonal, because *if* preempt-RT patch becomes guaranteed hard-RT, it 
> 
> I don't see how can preempt-RT ever become hard-RT when a simple lock
> hangs it. 

There is no "simple lock" as spinlock (or very very few). All locks are
mutexes - with priority inheritance! Ofcourse, hitting a lock which can be
held for a non-deterministic amount of time destroyes your RT - but so it
does in any  RTOS. 
The whole point of PREEMPT_RT is that what _other_, lower priority threads
are doing isn't going to affect you. They are _not_ disabling preemption
or locking you away. Ofcourse, as soon as you start to share resources
with other threads you have to be carefull. But priority inheritance
even makes that deterministic - provided that all code used under the lock
is deterministic. Same as for any RTOS.

> As soon as you call kernel code, you'll eventually hang,
> kmalloc will have to allocate memory and pageout other stuff no matter
> what.

Please, tell me why you think mlockall() doesn't protect my RT thread
against that problem. In the testcode I have made and run I have no
problems in practise, but I have not verified it by going through all the
mm-code. You know that code a whole lot better than I.

> 
> I really hope embedded developers knows better and they don't get the
> idea of using preempt-RT where hard-RT is required.

I hope people will stop making such broad statements and reallize that
Linux can become a hard-RT OS (if not by "proof", at least by
meassurement). There is no conflict between a timesharing system scaling
to a lot of CPUs and a hard-RT system just because they are catogarized as
different in the text-books.

Esben

-
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/