linux-kernel - Re: [PATCH 00/23] per device dirty throttling -v8

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:	Wed, 08 Aug 2007 14:22:04 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, J??rn Engel <joern@...fs.org>,
	Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	miklos@...redi.hu, akpm@...ux-foundation.org, neilb@...e.de,
	dgc@....com, tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
	trond.myklebust@....uio.no, yingchao.zhou@...il.com,
	richard@....demon.co.uk, david@...g.hm
Subject: Re: [PATCH 00/23] per device dirty throttling -v8

Ingo Molnar wrote:

> || ...For me, I would say 50% is not enough to describe the _visible_ 
> || benefits... Not talking any specific number but past 10sec-1min+ 
> || lagging in X is history, it's gone and I really don't miss it that 
> || much... :-) Cannot reproduce even a second long delay anymore in 
> || window focusing under considerable load as it's basically 
> || instantaneous (I can see that it's loaded but doesn't affect the 
> || feeling of responsiveness I'm now getting), even on some loads that I 
> || couldn't previously even dream of... [...]
> 
> we really have to ask ourselves whether the "process" is correct if 
> advantages to the user of this order of magnitude can be brushed aside 
> with simple "this breaks binary-only HSM" and "it's not standards 
> compliant" arguments.
> 
Being standards compliant is not an argument it's a design goal, a 
requirement. Standards compliance is like pregant, you are or you're 
not. And to deliberately ignore standards for speed is saying "it's too 
hard to do it right, I'll do it wrong and it will be faster." The answer 
is to do it smarter, with solutions like relatime (which can be enhanced 
as Linus noted) which provide performance benefits without ignoring 
standards, or use of a filesystem which does a better job. But when it 
goes in the kernel the choice of having per-filesystem behavior either 
vanishes or becomes an exercise in complex and as-yet unwritten mount 
options.

There are certainly ways to improve ext3, not journaling atime updates 
would certainly be one, less frequent updates of dirty inodes, whatever. 
But if a user wants to give up standards compliance it should be a 
deliberate choice, not something which the average user will not 
understand or learn to do.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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/