Re: [RFC][PATCH] Restricted hard realtime

[Ingo Molnar <mingo@elte.hu>]

* Andrew Morton <akpm@osdl.org> wrote:

> I have a sneaking suspicion that the day will come when we get nice
> sub-femtosecond latencies in all the trivial benchmarks [...]

with -RT-V0.3 i get lower than 20 usec _maximum_ latencies during
'./hackbench 20'. (the average latency is 1 usec) So while i'm not yet
in the sub-femtosecond category, things are looking pretty good in
PREEMPT_REALTIME land :)

> [...] but it turns out that the realtime processes won't be able to
> *do* anything useful because whenever they perform syscalls, those
> syscalls end up taking long-held locks.

this is not really a problem for the following reason: the spinlock
lock-breaks i am doing for !PREEMPT_REALTIME are exactly the kind of
latencies that could interact with a hard-RT task. What becomes a
latency reducer for the normal SMP or desktop kernel is _the_ latency
guarantee for using arbitrary kernel services in the PREEMPT_REALTIME
model.

another step is to make kernel subsystems have constant overhead (O(1)),
i'd say that's mostly true already today, and it's increasingly becoming
true in the future.

also, RT applications rarely hit the really complex kernel subsystems
because 'complex' often means 'has the potential for IO' - on any
hard-RT OS. So what is important are two factors:

 1) preempt to the RT app immediately

 2) do not create locking interactions between a tasks that use 
    'isolated resources'

#1 is quite good in PREEMPT_REALTIME, and even #2 is largely true for 
it. But RT apps will try to stay isolated anyway, they do an mlockall()
and use simple syscalls.

note that #2 means: 'no big locks', which is a natural scalability
desire anyway.

> Which does lead me to suggest that we need to identify the target
> application areas for Ingo's current work and confirm that those
> applications are seeing the results which they require.  Empirical
> results from the field do seem to indicate success, but I doubt if
> they're sufficiently comprehensive.

with the -V series of PREEMPT_REALTIME the 'preemption latency' target
is easy to meet, because in essence everything except the core scheduler
and the irq redirection code is preemptible :)

E.g. the innermost loop of the IDE hardirq is preemptible, the innermost
loop of kswapd is preemptible and PREEMPT_REALTIME can preempt the
pagefault handler and the mouse handler - name any code and it's
preemptible.

the API latency target is not a big issue because the 'locking
independence' requirement (#2 above) directly corresponds to 'good
scalability on SMP and NUMA'. So anytime we improve high-end scalability
we often will also improve the API-latencies of PREEMPT_REALTIME!

(of course this is a much simplified reasoning ignoring a few issues.)

	Ingo