Messages in this thread | | | Date | Tue, 22 Nov 2005 06:08:56 -0200 | From | Marcelo Tosatti <> | Subject | Re: [PATCH] properly account readahead file major faults |
| |
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.
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).
I don't think the semantics are precisely defined anywhere are they? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |