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] [day] [month] [year] [list]

Date:	Mon, 22 Oct 2007 02:49:33 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
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

On Mon, 22 Oct 2007 11:40:14 +0200 Ingo Molnar <mingo@...e.hu> wrote:

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

None of which is an argument for simply not bothering to do a bit more
developer testing before merging.

-
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/