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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Sun Jan 28 2001 - 16:19:37 EET


yodaiken_AT_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.

-


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jan 30 2001 - 17:26:44 EET