* Andrew Morton <[email protected]> wrote:
> > so lets just goddamn apply this _trivial_ patch. This isnt an
> > intrusive 1000 line rewrite that is hard to revert. If it causes any
> > bandwidth problems, it will be just as trivial to undo. If we do
> > anything else we just stiffle the still young and very much
> > under-represented "lets fix latencies that bothers people" movement.
> > If anything we need _positive_ discrimination for latency related
> > fixes (which treatment this fix does not need at all - all it needs
> > is _equal_ footing with the countless bandwidth patches that go into
> > the kernel all the time), otherwise it will never take off and
> > become as healthy as bandwidth optimizations. Ok?
>
> I think the situation is that we've asked for some additional
> what-can-be-hurt-by-this testing.
>
> Yes, we could sling it out there and wait for the reports. But often
> that's a pretty painful process and regressions can be discovered too
> late for us to do anything about them.
reverting this oneliner is trivial. Finding bandwidth problems and
tracking them down to this oneliner change is relatively easy too.
Finding latency problems and fixing them is _not_ trivial.
Boot up a Linux desktop and start OOo or firefox, and measure the time
it takes to start the app up. 10-20 seconds on a top-of-the-line
quad-core 3.2 GHz system - which is a shame. Same box can do in excess
of 1GB/sec block IO. Yes, one could blame the apps but in reality most
of the blame is mostly on the kernel side. We do not make bloat and
latency suckage apparent enough to user-space (due to lack of
intelligent instrumentation), we make latencies hard to fix, we have an
acceptance bias towards bandwidth fixes (because they are easier to
measure and justify) - and that's all what it takes to let such a
situation get out of control.
and i can bring up the scheduler as an example. CFS broke the bandwidth
performance of one particular app and it took only a few days to get it
back under control. But it was months to get good latency behavior out
of the scheduler. And that is with the help of excellent scheduler
instrumentation. In the IO space the latency situation is much, much
worse. Really.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
