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

[Ingo Molnar]

* Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> And you honestly think that putting it in Kconfig as well as allowing 
> users to screw up horribly and creating incompatible defaults you

So far you've not offered one realistic scenario of "screw up horribly". 
People have been using noatime for a long time and there are no horror 
stories about that. _Which_ OSS HSM software relies on atime?

> can't test for in a user space app where it matters is going to 
> *change* this.

The patch i posted today adds /proc/sys/kernel/mount_with_atime. That 
can be tested by user-space, if it truly cares about atime.

> Do you really think anyone who said "noatime, compatibility, umm errr" 
> is going to say "noatime, compatibility, but hey its in Kconfig lets 
> do it". You argument doesn't hold up to minimal rational 
> consideration. Posting to the distribution devel list with: "Its a 50% 
> performance win, we need to fix these corner cases, here's a tmpwatch 
> patch" is *exactly* what is needed to change it, and Kconfig options 
> are irrelevant to that.

i did exactly that 6 months ago, check your email folders. I went by the 
"process". But it doesnt really matter anymore, Ubuntu has done the step 
and Fedora will be forced to do it too. But it's sad that it took us 10 
years. I'd like to remind you again:

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

	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/