Re: [PATCH] properly account readahead file major faults

[Charles Ballowe <cballowe@gmail.com>]

On 11/22/05, Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> Hi Hugh!
>
> On Tue, Nov 22, 2005 at 12:55:02PM +0000, Hugh Dickins wrote:
> > On Tue, 22 Nov 2005, Marcelo Tosatti wrote:
> > >
> > > Pages which hit the first time in cache due to readahead _have_ caused
> > > IO, and as such they should be counted as major faults.
> >
> > Have caused IO, or have benefitted from IO which was done earlier?
>
> Which caused IO, either synchronously or via (previously read)
> readahead.
>
> > It sounds debatable, each will have their own idea of what's major.
>
> I see your point... and I much prefer the "majflt means IO performed"
> definition :)
>
> As a user I want to know how many pages have been read in from disk to
> service my application requests.

This is a dangerous line of thought. While the number of pages read in
does have some meaning, in many cases, fetching one page vs. 1MB worth
of pages takes about the same time to service. If the page read-ahead
manages to do larger multi-block reads, then there is only 1 I/O for
the fault, regardless of the number of pages that are read in by that
operation.

> From the "time" manpage:
>
> F      Number of major, or I/O-requiring, page faults  that  oc-
>        curred  while  the process was running.  These are faults
>        where the page has actually migrated out of primary memo-
>        ry.
>
> > Maybe PageUptodate at the time the entry is found in the page cache
> > should come into it?  !PageUptodate implying that we'll be waiting
> > for read to complete.
>
> Hum, I still strongly feel that users care about IO performed and not
> readahead effectiveness (which could be separate information).

>From a user perspective, I'm far more interested in number of I/O
operations performed rather than pages read. The first has a far
larger effect on time spent waiting than the second.

Just my opinons,
-Charlie

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>