Re: [PATCH] properly account readahead file major faults

[Marcelo Tosatti]

Hi Wu!

On Tue, Nov 22, 2005 at 12:24:43PM +0800, Wu Fengguang wrote:
> Hi,
> 
> On Mon, Nov 21, 2005 at 12:00:38PM -0200, Marcelo Tosatti wrote:
> > Hi,
> > 
> > The fault accounting of filemap_dopage() is currently unable to account
> > for readahead pages as major faults.
> 
> Sorry, I don't know much about the definition of major/minor page faults.
> So I googled one that explains the old behavior:
> 
> --> Page Faults <--
> These come in two varieties. Minor and Major faults. A Major fault results
> when an application tries to access a memory page that has been swapped out to
> disk. The page must be swapped back in. A Minor fault results when an
> application tries to access a memory page that is still in memory, but the
> physical location of which is not immediately known. The address must be
> looked up.

Yep, just that "swapped out"/"swappin in" can be though of as "read
in/"read out".

> With the current accounting logic:
> - major faults reflect the times one has to wait for real I/O.
> - the more success read-ahead, the less major faults.
> - anyway, major+minor faults remain the same for the same benchmark.
> 
> With your patch:
> - major faults are expected to remain the same with whatever read-ahead.
> - but what's the new meaning of minor faults?

With the patch minor faults are only those faults which can be serviced
by the pagecache, requiring no I/O.

Pages which hit the first time in cache due to readahead _have_ caused
IO, and as such they should be counted as major faults.

I suppose that if you want to count readahead hits it should be done
separately (which is now "sort of" available with the "majflt" field).

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