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

[Ingo Molnar]

* Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> Either change is a big user/kernel interface change and no major 
> vendor targets desktop as primary market so I'm not suprised they 
> haven't done this. [...]

earlier in the thread it was claimed that Ubuntu is now defaulting to 
noatime+nodiratime, and has done so for several months. Could be one of 
the reasons why:

   http://www.google.com/trends?q=fedora%2C+ubuntu

> People just need to know about the performance differences - very few 
> realise its more than a fraction of a percent. I'm sure Gentoo will 
> use relatime the moment anyone knows its > 5% 8)

noatime,nodiratime gave 50% of wall-clock kernel rpm build performance 
improvement for Dave Jones, on a beefy box. Unless i misunderstood what 
you meant under 'fraction of a percent' your numbers are _WAY_ off. 
Atime updates are a _huge everyday deal_, from laptops to servers. 
Everywhere on the planet. Give me a Linux desktop anywhere and i can 
tell you whether it has atimes on or off, just by clicking around and 
using apps (without looking at the mount options). That's how i notice 
it that i forgot to turn off atime on any newly installed system - the 
system has weird desktop lags and unnecessary disk trashing.

> [...] Ext3 currently is a standards compliant file system. Turn off 
> atime and its very non standards compliant, turn to relatime and its 
> not standards compliant but nobody will break (which is good)

come on! Any standards testsuite needs tons of tweaks to the system to 
run through to completion. Mounting the filesystem atime will just be 
one more item in the long list of (mostly silly) 'needed for standards 
compliance' items (most of which nobody configures). What matters are 
the apps, and nary any app depends on atime, and those people who depend 
on them can turn on atime just fine. (it's the same as for extended 
attributes for example - and attributes are infinitely _more_ useful 
than atime.)

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