Messages in this thread |  | | Subject | Re: low-latency patches | From | Robert Love <> | Date | 06 Oct 2001 21:12:34 -0400 |
| |
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/
|  |