Messages in this thread | | | Date | Wed, 1 Dec 2004 16:58:27 -0200 | From | Marcelo Tosatti <> | Subject | Re: [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/
| |