Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>This all came up before in a previous flamewar.  Reducing Linux's
>scheduling latency and overhead is good.  Trying to make Linux serve the
>contradictory goals of being both a good timesharing OS and a good
>realtime OS is not.  Thinking that you are making Linux into a realtime
>OS by reducing scheduling latency and overhead is a fallacy.

Sorry, but this is nonsense. Not because you're wrong about the
distinction between a TS and an RT OS. You're wrong because we don't
need the full set of features that an RT OS comes with.

Imagine that Linux was a preemptable kernel (I'm *not* advocating it,
just using it as an example), and we ensure that our audio thread has
the highest SCHED_FIFO priority, and we ensure that interrupts are
never disabled for more than a few usecs. 

Under these circumstances, add an audio interface with an interrupt
occuring regularly. Each time the handler runs, it makes our
SCHED_FIFO audio thread ready to run. The return from the handler
always causes our audio thread to move back onto the processor. Given
that the thread can have mlocked all its memory, and that it was
properly written to never do disk i/o or block on any other system
resource, we will get precisely the behaviour we desire.

However, Linux is not currently preemptable in this way, and so the
return from interrupt doesn't always cause the desired thread to
run. as andrea summarised very nicely: its the delay between the
discovery that current->need_resched is set and the reschedule
actually happening is the source of these problems.

A true RT OS can make much broader guarantees about resource
availability and so forth. we (the audio+MIDI linux community) are
*NOT* asking for that. 

We know that if our thread does disk i/o or ends up paging, it could
block for an indeterminate amount of time. we know that if its uses
other system resources, it could fail to meet deadlines. thats
*OK*. we can design audio threads to do the right thing (and in fact,
we already do).

But as long as there is a the chance of a significant delay between
the interrupt that makes our SCHED_FIFO audio thread runnable again,
and it actually getting back on the processor, we can't make a number
of very useful (and very fun) things work correctly.

--p