Re: RT patch acceptance

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andi Kleen wrote:

>>>What I dislike with RT mutexes is that they convert all locks.
>>>It doesnt make much sense to me to have a complex lock that
>>>only protects a few lines of code (and a lot of the spinlock
>>>code is like this). That is just a waste of cycles.
>>>
>>
>>It is NOT just a few lines of code. Millisecond latencies on high-
>>powered CPU systems means more code than is probably required to send a
>>rocket 'round the moon and back.
> 
> 
> Most spinlocks only protect small code parts. Those that protect
> larger codes can probably use optionally some different lock.
> 
> But dont attack it with "one size fits all" locking please.
> 

I have a question about what sort of RT guarantees people might
want. Forget specific patches or implementations for a minute.
I'm genuinely curious, as an uneducated bystander - I want to get
a bit more background about this.


Presumably your RT tasks are going to want to do some kind of
*real* work somewhere along the line - so how is that work provided
guarantees?

For example, suppose you have preemptible everything, and priority
inheritance and that's all nice. But the actual time in which
some thread holds a lock is time that no other thread can take
that lock either, regardless of its priority.

So in that sense, if you do hard RT in the Linux kernel, it surely
is always going to be some subset of operations, dependant on
exact locking implementation, other tasks running and resource usage,
right?

Tasklist lock might be a good example off the top of my head - so
you may be able to send a signal to another process with deterministic
latency, however that latency might look something like: x + nrproc*y

It appears to me (uneducated bystander, remember) that a nanokernel
running a small hard-rt kernel and Linux together might be "better"
for people that want real realtime.

Just from the point of view of making the RT kernel as small and easy
to verify as possible, and not having to provide for general purpose
non-RT tasks. Then you also get the benefit of not having to make the
general purpose Linux support hard real time.

For example, if your RT kernel had something like a tasklist lock, it
may have an upper limit on the number of processes, or put in restart
points where lower priority processes drop the lock and restart what
they were doing if a high prio process one comes along - obviously
neither solution would fly for the Linux tasklist lock.

Or have I missed something completely? You RT guys have thought about
it - so what are some pros of the Linux-RT patch and/or cons of the
nanokernel approach, please?

[ And again, please don't say why Ingo's RT patch should go in, I'm
   not talking about any patch, any merging of patches or even that
   some hypothetical patch *shouldn't* go in - even if it does have
   above problem ;) ]

Thanks very much,
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com