lkml.org 
[lkml]   [2005]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-11-22 14:39    [W:0.050 / U:9.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site