linux-kernel - Re: [patch] Give kjournald a IOPRIO_CLASS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Oct 2007 11:10:57 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] Give kjournald a IOPRIO_CLASS_RT io priority

* Jens Axboe <jens.axboe@...cle.com> 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)

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?

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/