Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Nigel Gamble]

On Wed, 10 Jan 2001, David S. Miller wrote:
> Opinion: Personally, I think the approach in Andrew's patch
> 	 is the way to go.
> 
> 	 Not because it can give the absolute best results.
> 	 But rather, it is because it says "here is where a lot
>          of time is spent".
> 
> 	 This has two huge benefits:
> 	 1) It tells us where possible algorithmic improvements may
> 	    be possible.  In some cases we may be able to improve the
> 	    code to the point where the pre-emption points are no
> 	    longer necessary and can thus be removed.

This is definitely an important goal.  But lock-metering code in a fully
preemptible kernel an also identify spots where algorithmic improvements
are most important.

> 	 2) It affects only code which can burn a lot of cpu without
> 	    scheduling.  Compare this to schemes which make the kernel
> 	    fully pre-emptable, causing _EVERYONE_ to pay the price of
> 	    low-latency.  If we were to later fine algorithmic
> 	    improvements to the high-latency pieces of code, we
>             couldn't then just "undo" support for pre-emption because
> 	    dependencies will have swept across the whole kernel
> 	    already.
> 
>             Pre-emption, by itself, also doesn't help in situations
> 	    where lots of time is spent while holding spinlocks.
> 	    There are several other operating systems which support
> 	    pre-emption where you will find hard coded calls to the
> 	    scheduler in time-consuming code.  Heh, it's almost like,
> 	    "what's the frigging point of pre-emption then if you
> 	    still have to manually check in some spots?"

Spinlocks should not be held for lots of time.  This adversely affects
SMP scalability as well as latency.  That's why MontaVista's kernel
preemption patch uses sleeping mutex locks instead of spinlocks for the
long held locks.  In a fully preemptible kernel that is implemented
correctly, you won't find any hard-coded calls to the scheduler in time
consuming code.  The scheduler should only be called in response to an
interrupt (IO or timeout) when we know that a higher priority process
has been made runnable, or when the running process sleeps (voluntarily
or when it has to wait for something) or exits.  This is the case in
both of the fully preemptible kernels which I've worked on (IRIX and
REAL/IX).

Nigel Gamble                                    [e-mail]
Mountain View, CA, USA.                         http://www.nrg.org/