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:4.952 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site