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