Re: a joint letter on low latency and Linux

[Linus Torvalds]

On Fri, 30 Jun 2000, Benno Senoner wrote:
> 
> 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.

We don't run bonnie every time, but yes, we run it occasionally to see
that things are still ok. And when they aren't, we try to fix them. I
think the same should be true of low latency.

I'd be quite happy to apply the copy_to/from_user() part, for example, and
then let's see what the other problem-spots are, and how they should be
properly fixed. The copy_to/from_user() case is quite simple to
understand, and there really aren't that many alternatives to handling it.

> 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)

I can apply the obvious stuff today. But it would need to be a clean
patch, and I suspect that the only part that I would consider truly
obvious would be the user copy part. And adding a test for "need_resched"
does imply not inlining them any more, it's already border-line, and the
re-scheduling makes it obviously so (by the time you can potentially call
"schedule()", the compiler has to save/restore all the call-clobbered
registers anyway, so 90% of the advantages of inlining have been
destroyed, making the disadvantages like icache footprint etc clear).

Note that regardless of _what_ the problem is, I always prefer incremental
patches anyway. Maybe people in the end can convince me that every single
scheduling point makes 100% sense, and is not a hack at all but a natural
thing. Even if that were the case, I'd like to get the thing in smaller
and explainable pieces..

			Linus