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

[Andrew Morton <andrewm@uow.edu.au>]

yodaiken@fsmlabs.com wrote:
> 
> ...
> 
> I suggest that you get your hearing checked. I'm fully in favor of sensible
> low latency Linux. I believe however that low latency  in Linux will
>         A. be "soft realtime", close to deadline most of the time.
>         B. millisecond level on present hardware
>         C. Best implemented by careful algorithm design instead of
>         "stuff the kernel with resched points" and hope for the best.

Point C would be nice, but I don't believe it will happen because of

a) The sheer number of problem areas
b) The complexity of fixing them this way and
c) The low level of motivation to make Linux perform well in
   this area.

Main problem areas are the icache, dcache, pagecache, buffer cache,
slab manager, filemap and filesystems.  That's a lot of cantankerous
cats to herd.

In many cases it just doesn't make sense.  If we need to unmap 10,000
pages, well, we need to unmap 10,000 pages.  The only algorithmic
redesign we can do here is to free them in 500 page blobs.  That's
silly because we're unbatching work which can be usefully batched.
You're much better off unbatching the work *on demand* rather than
by prior decision.  And the best way of doing that is, yup, by
peeking at current->need_resched, or by preempting the kernel.

There has been surprisingly little discussion here about the
desirability of a preemptible kernel.

> 
> Nice marketing line, but it is not working code.
> 

Guys, please don't.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/