Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>I want more than an explanation like "I ran our latency tester, and this
>point seemed to be really bad, so I added a scheduling point here". 

       [ ... read/write user-copy example elided ... ]

Understood.

>More than just numbers, but yes. I'd like to know that the code isn't just
>crap. For example, let's say that something uses an O(n^3) algorithm, and
>to "overcome" the expense of this thing we add scheduling points in it.
>That's the easy way to do it. But maybe the right thing to do is to
>realize that the code may be badly structured in the first place?

Clear. But I take it that if you were satisfied that an O(n^3)
algorithm really was the right solution, then scheduling points within
it would be a possibility from your perspective ?

>> Can someone explain what is meant by getting the UP-threaded kernel to
>> work ok, and how this would impact scheduling jitter ? If a kernel
>> thread blocks interrupts for a long time, how can it help to have a
>> multi-threaded kernel ?
>
>If the kernel blocks interrupts for a long time, adding re-scheduling
>points won't help. You must not schedule with interrupts blocked anyway.

Sure. As I understand it, we have two problems with latency:

      1) interrupts disabled, so the current->need_resched test
           is not done as frequently as it would otherwise be (and
	   would be irrelevant anyway, as you point out, since we
	   couldn't reschedule anyway)

      2) we're inside a long code path, no interrupts arrive,
           it takes a long time to reschedule

The second case is actually sort-of-irrelevant for audio work, since
all applications will have their primary audio thread driving/being
driven by an audio interface which is typically interrupting us every
1-5ms. 

*If* interrupts are being handled, and *if* current->need_resched is
checked on return from the handler (such was my understanding), and
the audio thread runs SCHED_FIFO, we get the desired performance
(given some other assumptions about its behaviour that are quite easy
to make and satisfy). Am I correct in thinking this ?

But the first case is problematic, and I think might be more of an
issue than the discussion has indicated so far. I think Ingo would
know more about this than anyone else, though others have done some
kernel profiling that speak to this as well. I do know, for example,
that an IDE-based disk subsystem has much worse impact on latency,
almost certainly because of the long periods of times for which those
drivers tend(ed?) to disable interrupts.

As a reference point, I've been told that BeOS never disables
interrupts for more than 50usec, except in some problematic drivers
for not-too-common hardware.

--p