lkml.org 
[lkml]   [2004]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH]: 1/4 batch mark_page_accessed()

    <snip>

    > > > On the other hand, without batching you mix the locality up in LRU - the LRU becomes
    > > > more precise in terms of "LRU aging", but less ordered in terms of sequential
    > > > access pattern.
    > > >
    > > > The disk IO intensive reaim has very significant gain from the batching, its
    > > > probably due to the enhanced LRU ordering (what Nikita says).
    > > >
    > > > The slowdown is probably due to the additional atomic_inc by page_cache_get().
    > > >
    > > > Is there no way to avoid such page_cache_get there (and in lru_cache_add also)?
    > >
    > > Not really. The page is only in the pagevec at that time - if someone does
    > > a put_page() on it the page will be freed for real, and will then be
    > > spilled onto the LRU. Messy.
    >
    > I don't think that atomic_inc will be particularly
    > costly. generic_file_{write,read}() call find_get_page() just before
    > calling mark_page_accessed(), so cache-line with page reference counter
    > is most likely still exclusive owned by this CPU.

    Assuming that is true - what could cause the slowdown?

    There are only benefits from the makr_page_accessed batching, I can't
    see any drawbacks. Do you?
    -
    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-03-22 14:08    [W:0.020 / U:0.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site