[lkml]   [2001]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: low-latency patches
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

> > 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:04    [W:0.071 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site