[lkml]   [2007]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Give kjournald a IOPRIO_CLASS_RT io priority

    * Andrew Morton <> 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.

    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: 2007-10-22 11:43    [W:0.024 / U:33.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site