>The best way to get kernel development to go in the direction that you
>want is to test and to give feedback (for each patch release).
>[you do also need to explain what kind of latency you are talking about]
With all due respect Roger, we gave Ingo *loads* of great feedback on
his patches. That's not the problem - the problem is that Linus
doesn't like what Ingo did. We would be quite happy if Ingo's stuff
had just gone straight into 2.3 at some early stage, but Linus vetoed
this, and there seems to be little sign of it being reversed.
As for defining the kind of latency we are talking about: well, yes,
its definitely a loose term, but in the context of Ingo's patches, the
meaning is very precise:
* reduce the amount of time that interrupts are disabled
(for reference, BeOS aims at 50usec)
* reduce or eliminate the holding of kernel locks that
are not directly related to the operation in
the critical section they protect (e.g. the "global"
kernel lock (already vanishing), or file system
locks used during audio I/O).
Ingo understands all this stuff very clearly, and so does Linus.
>People needing raw throughput are... it is easy.
>And there are several benchmarks developed.
>
>BTW, there are disk benchmarks that are a lot worse for latency than
>the ones included in Bennos latencytest: like Quintelas mmap002
I sent Linus a streaming mmap test some time ago. His response was
that mmap wasn't designed to support streaming I/O.
Benno did a nice fairly minimalist simulation of an HDR system. The
response to his test was ... close to zero.
Juan's test gets publicity because it is closer to the kind of thing
that people using Linux for "server applications" or "gimp-dom" are
doing. This is true even though Juan himself has clear interests in
streaming I/O.
As many people have noted, audio+MIDI applications are a niche market
in general, and an even tinier niche market for Linux. The attention
that our needs get has been pretty minimal, and Linus has even
expressed outright disdain for the idea that Linux should try to do
this stuff as well as BeOs. I/We hope to change all that.
--p
