[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070805180826.GD3244@elte.hu>
Date: Sun, 5 Aug 2007 20:08:26 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: 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 <alan@...rguk.ukuu.org.uk> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists