Re: a joint letter on low latency and Linux

[Benno Senoner]

On Fri, 30 Jun 2000, Linus Torvalds wrote:
> On Thu, 29 Jun 2000, Larry McVoy wrote:
> > 
> > I guess the problem I have is that I don't see a clean way to make sure
> > that no high latency events ever creep into the kernel.  I'm 100% in
> > agreement with the idea that all code paths through the kernel should
> > be short and sweet, but that isn't always the case.  All it takes is
> > one misbehaving driver that hangs onto the CPU too long and you missed
> > your deadline.
> 
> I agree. Badly written code will be a problem. The approach that the
> patches so far have taken is to just add scheduling points all over the
> map. 

But do you think the way to avoid that bad code (accidentally) gets into the
kernel, is to run extensive latency benchmarks (which should uncover the bad
code) each time a new kernel release comes out ?
Just like we run bonnie on each new kernel release in order to ensure that
we still get the full disk speed.

> 
> > I'd rather support RTLinux than see lots of kludges being slipped into
> > the generic kernel.
> 
> In many cases I just think that RTLinux is a worse fix than the disease. I
> think RTLinux is perfect for those things that truly need latency
> guarantees: no OS at _all_ in the way. But using it for "normal" stuff
> like just streaming audio and video is overkill. They don't have
> microsecond latency requirements.

Amen.

Linus, to remove my last doubts:
(I think I will write a FAQ out of all stuff I collected today)

assume someone rolls out a clean low latency approach for 2.4 ,
would you accept the patches or would you delay the stuff to 2.5 ?
(I have no idea if it is a big amount of work)

there are people that want to use low latency applications now:
should we encourage the use of Ingo's kernels 
(which said he will do a 2.4 version of his 2.2 patches too),
perhaps by providing RPMs (or DEBs) with the patched kernels for the various 
distros, so that it will me more easy for beginners to use it ?

(adding a statement saying that the current lowlatency kernels achieve their
performance by rescheduling points (which is a bit of a hack), but that future
linux kernels will deliver similar performance using the clean design , meaning
that future linux distos will include the "well realtime-performing" kernel by
default.

> 
> 		Linus

cheers,
Benno.