[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-mm
Subject: Re: [PATCH]: 1/4 batch mark_page_accessed()
From: Marcelo Tosatti <marcelo.tosatti () cyclades ! com>
Date: 2004-11-30 22:57:07
Message-ID: 20041130225707.GA2315 () dmt ! cyclades
[Download RAW message or body]
On Tue, Nov 30, 2004 at 05:33:23PM -0800, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > Because the ordering of LRU pages should be enhanced in respect to locality,
> > with the mark_page_accessed batching you group together tasks accessed pages
> > and move them at once to the active list.
> >
> > You maintain better locality ordering, while decreasing the precision of aging/
> > temporal locality.
> >
> > Which should enhance disk writeout performance.
>
> I'll buy that explanation. Although I'm a bit sceptical that it is
> measurable.
Its just a theory that makes sense to me, but yes we need to be measure it.
> Was that particular workload actually performing significant amounts of
> writeout in vmscan.c? (We should have direct+kswapd counters for that, but
> we don't. /proc/vmstat:pgrotated will give us an idea).
I strongly believe so, its a memory hungry benchmark - I'll collect status later
on this week or the next.
> > 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.
We could handle such situation on allocation and during vmscan - maybe its doable.
Just pondering, maybe its indeed too messy to even ponder about.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic