[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
    On Mon, 22 Oct 2007 11:10:57 +0200 Ingo Molnar <> wrote:

    > * Jens Axboe <> wrote:
    > > > Seems a pretty fundamental change which could do with some careful
    > > > benchmarking, methinks.
    > > >
    > > > See, your patch amounts to "do more seeks to improve one test case".
    > > > Surely other testcases will worsen. What are they?
    > >
    > > Yes, completely agree! I think Arjans patch makes a heap of sense, but
    > > some numbers would be great to see.
    > Arjan gave the relevant hard numbers:
    > | With latencytop, I noticed that the (in memory) atime updates during a
    > | kernel build had latencies of 600 msec or longer [...]
    > |
    > | With this patch, the latencies for atime updates (and similar
    > | operation) go down by a factor of 3x to 4x !
    > atime update latencies went down by a factor of 3x-4x ...
    > but what bothers me even more is the large picture. Linux's development
    > is still fundamentally skewed towards bandwidth (which goes up with
    > hardware advances anyway), while the focus on latencies is very lacking
    > (which users do care about much more and which usually does _not_
    > improve with improved hardware), so i cannot see why we shouldnt apply
    > this. Reminds me of the illogical, almost superstitious resistence
    > against the relatime patch. (which is not in 2.6.24 mind you - killed
    > for good)

    Try `mount -o relatime' and prepare to be surprised ;)

    > if bandwidth hurts anywhere, it will be pointed out and fixed, we've got
    > like tons of bandwidth benchmarks and it's _easy_ to fix bandwidth
    > problems. But _finally_ we now have desktop latency tools, hard numbers
    > and patches that fix them, but what do we do ... we put up extra
    > roadblocks??
    > 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.

    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:27    [W:0.023 / U:42.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site