On Sat, 2001-10-06 at 02:46, Andrew Morton wrote:
> [...]
> > My questions are:
> > 1) Which of these two projects has better latency performance? Has anyone
> > benchmarked them against each other?
>
> I haven't seen any rigorous latency measurements on Rob's stuff, and
> I haven't seriously measured the reschedule-based patch for months. But
> I would expect the preempt patch to perform significantly worse because
> it doesn't attempt to break up the abovementioned long-held locks. (It can
> do so, though - a straightforward adaptation of the reschedule patch's
> changes will fix it).
We've gotten some great benchmarks (I originally asked all the users for
them), I would be happy to send some your way if I can dig them up.
Basically we saw average latency drop to under 5ms; 1ms in many cases.
Worst-case latency tended to be around 50ms, but we have measured locks
(using the preempt-stats) which are still in the way-to-long range.
I think preemption is a very natural and clean solution the problem --
its the way things should just be, anyhow.
Nonetheless, running a lock-breaking patch on top of preemption is
interesting. I am looking into doing this with the lock times I have
collected.
> > 2) Will either of these ever be merged into Linus' kernel (2.5?)
>
> Controversial. My vague feeling is that they shouldn't. Here's
> why:
>
> The great majority of users and applications really only need
> a mostly-better-than-ten-millisecond latency. This gives good
> responsiveness for user interfaces and media streaming. This
> can trivially be achieved with the current kernel via a thirty line
> patch (which _should_ be applied to 2.4.x. I need to get off my
> butt).
>
> But the next rank of applications - instrumentation, control systems,
> media production sytems, etc require 500-1000 usec latencies, and
> the group of people who require this is considerably smaller. And their
> requirements are quite aggressive. And maintaining that performance
> with either approach is a fair bit of work and impacts (by definition)
> the while kernel. That's all an argument for keeping it offstream.
With preemption, we can gain the <10ms that most "regular" users want.
Without it, we don't have it.
With preemption, we can come super close to the 0.5-1ms latency (on
average) the specialized groups list want. With preemption and perhaps
some other work (something akin to your low-latency patch) we can
achieve it for sure ... perhaps better.
If we can achieve such great results, and keep throughput low, and do it
with such little complexity -- of course, after we prove all this -- why
not merge it? Anyhow, its a configure option!
> [...]
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:43 EST