Re: a joint letter on low latency and Linux

[Andi Kleen]

On Thu, Jun 29, 2000 at 11:14:49PM -0400, Paul Barton-Davis wrote:
> 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 ?

current->need_resched is checked on return from the handler, but it is 
only acted on directly when the CPU is running in user space.

So you have

	3) you're in a long code path in the kernel, interrupts arrive, but 
	   the code path doesn't check need_resched 

This can be done in two ways: 

	- Use Linus' trick of a multi threaded UP kernel using
	  SMP locks (2.5 material), also hated by Larry/Victor.

	- Add explicit need_resched checks in long latency paths as 
	  needed (what Ingo's patch does) 

The second one is probably the only feasible in 2.4 timeframe. 

Do you have any data which long code paths are the problem ? 
If you have maybe you should post a list weekly to linux-kernel ;)

Also BTW there seem to be some scheduler bugs related to SCHED_FIFO
that are only fixed by Dimitris Michailidis' scheduler patch kit.
If you care about that it probably needs to be included too.

-Andi