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:40:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] Give kjournald a IOPRIO_CLASS_RT io priority

* Andrew Morton <akpm@...ux-foundation.org> 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 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/