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