Re: [PATCH]: 1/4 batch mark_page_accessed()

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

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