On Fri, 2007-08-10 at 21:43 +0000, Martin Ebourne wrote: > On Fri, 10 Aug 2007 15:09:11 +0200, Ralf Corsepius wrote: > > On Fri, 2007-08-10 at 07:59 -0400, James Hubbard wrote: > >> Just because it's a fundamental feature doesn't mean that it has to be > >> used. Fundamentally, my CPU can run at 2GHz all of the time that > >> doesn't mean that it should. If 99% of the applications can do without > >> it and probably 99% of the people can as well, why not go ahead and get > >> disable it. > > That's what people call "arrogance of the masses". Let's kill that 1%, > > if 99% don't care! > > Nobody's killing anybody, You would - You would kill all applications which rely on atime. Not that many applications will do so, but it's not hard to imagine one. An example would be apps cleaning up/removing files based on atime. > > <sarcasm> > > It's the same argument why people argue against utf-8, work as root > > (don't need uid/gids) and don't want SELinux? > > > > Let's remove all of this from the kernel, single seat/single user > > systems don't need all this at all. > > </sarcasm> > > No it's not, that's all completely unrelated. Not? I disagree. You want a "fundamental feature, most users don't need/want" to be disabled to gain performance. What I listed above is along the same rationale. > > A friend of mine experimented with atime/noatime yesterday: > > These were his results: > > Test case: A heavy weight compiler-job > > new / old = .9465 > > That's over 5% performance improvement, Well, whether 5% is "much" is arguable. On many occasions, you won't even notice because it will get lost in the jitter other factors impose. Take out SELinux, gain "x %". Don't use kde, gain "x %". Use "lean mail browser", gain "x %". Use gcc-<version>, gain another 20%. Don't have "big application" running in the background, gain "x %". Buy a better harddisk, gain "x %". > a huge amount for such a simple > change. I'll bet most of the difficult kernel optimisations are winning > less than that. Agreed, but with regard to compiler turn-around times, 5% is below the jitter of other factors, such as differences in compilation speed between different versions of GCC and differences in the impact of compilation-flags being used in GCC. > Now imagine the number of files touched on a boot, or logging into the > GUI and how much difference it makes there. (For hard numbers on the > 10,000s of files touched read Dave Jones's blog.) Make /usr, /bin, /sbin etc. read-only, consider noatime on /home, atime on /var, /tmp would be a reasonable approach. > Personally I can't believe its taken this long for people to sit up and > take notice of atime which was pretty much a design failure from the > start. Well, IIRC, noatime exists for circa a decade. Also, IIRC, this is not the first time of such a proposal. I recall SuSE devs having recommended it to me many years ago (ca. 2000) when facing "jerky" desktop behavior at that time. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
