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]

Message-ID: <46B8C382.1070106@tmr.com>
Date:	Tue, 07 Aug 2007 15:09:54 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Ingo Molnar <mingo@...e.hu>, 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

Alan Cox wrote:
>> i cannot over-emphasise how much of a deal it is in practice. Atime 
>> updates are by far the biggest IO performance deficiency that Linux has 
>> today. Getting rid of atime updates would give us more everyday Linux 
>> performance than all the pagecache speedups of the past 10 years, 
>> _combined_.
>>
>> it's also perhaps the most stupid Unix design idea of all times. Unix is 
>> really nice and well done, but think about this a bit:
> 
> Think about the user for a moment instead. 
> 
> Do things right. The job of the kernel is not to "correct" for
> distribution policy decisions. The distributions need to change policy.
> You do that by showing the distributions the numbers. 
> 
> With a Red Hat on if we can move from /dev/hda to /dev/sda in FC7 then we
> can move from atime to noatime by default on FC8 with appropriate release
> note warnings and having a couple of betas to find out what other than
> mutt goes boom.

Is there really enough benefit between relatime and noatime to justify 
that? If atime doesn't get updated at all it *will* impact operations, 
and unless there's a real performance gain the path which provides at 
least nominal POSIX compliance seems best.

Plauger's law of least astonishment.

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