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

Ingo Molnar
2007-08-06T06:52:56Z

* david@lang.hm <david@lang.hm> wrote:

> i've been a linux sysadmin for 10 years, and have known about noatime
> for at least 7 years, but I always thought of it in the catagory of
> 'use it only on your performance critical machines where you are
> trying to extract every ounce of performance, and keep an eye out for
> things misbehaving'
>
> I never imagined that itwas the 20%+ hit that is being described, and
> with so little impact, or I would have switched to it across the board
> years ago.
>
> I'll bet there are a lot of admins out there in the same boat.
>
> adding an option in the kernel to change the default sounds like a
> very good first step, even if the default isn't changed today.

yep - but note that this was a gradual effect along the years, today the
assymetry between CPU performance and disk-seek performance is
proportionally larger than 10 years ago. Today CPUs are nearly 100 times
faster than 10 years ago, but disk seeks got only 2-3 times faster. (and
even that only if you have a high rpm disk - most desktops dont.)

10 years ago noatime was a nifty hack that made a difference if you had
lots of files. But it still was a problem with no immediate easy
solution and people developed their counter-arguments. Today the same
counter-arguments are used, but the situation has evolved alot.

and note that often this has a bigger everyday effect than the tweaking
of CPU scheduling, IO scheduling or swapping behavior (!). My desktop
systems rarely swap, have plenty of CPU power to spare, but atime
updates still have a noticeable latency impact, regardless of the memory
pressure. Linux has _lots_ of "performance reserves", so people dont
normally notice when comparing it to other OSs, but still we should not
be so wasteful with our IO performance, for such a fundamental thing as
reading files.

Ingo