From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lin Ming <ming.m.lin@intel.com>,
Zhang Yanmin <yanmin_zhang@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/25] Cleanup and optimise the page allocator V5
Date: Fri, 20 Mar 2009 16:41:36 +0000 [thread overview]
Message-ID: <20090320164136.GQ24586@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.1.10.0903201203340.28571@qirst.com>
On Fri, Mar 20, 2009 at 12:04:42PM -0400, Christoph Lameter wrote:
> On Fri, 20 Mar 2009, Mel Gorman wrote:
>
> > hmm, I'm missing something in your reasoning. The contention I saw for
> > zone->lru_lock
> >
> > &zone->lru_lock 37350 [<ffffffff8029d6fe>] ____pagevec_lru_add+0x9c/0x172
> > &zone->lru_lock 55423 [<ffffffff8029d377>] release_pages+0x10a/0x21b
> > &zone->lru_lock 402 [<ffffffff8029d9d9>] activate_page+0x4f/0x147
> > &zone->lru_lock 6 [<ffffffff8029dbbd>] put_page+0x94/0x122
> >
> > So I just assumed it was LRU pages being taken off and freed that was
> > causing the contention. Can SLUB affect that?
>
> No. But it can affect the taking of the zone lock.
>
True although almost anything will affect the timining of when it's
taken.
> > Maybe you meant zone->lock and SLUB could tune buffers more to avoid
> > that if that lock was hot. That is one alternative but the later patches
> > proposed an alternative whereby high-order and compound pages could be
> > stored on the PCP lists. Compound only really helps SLUB but high-order
> > also helped stacks, signal handlers and the like so it seemed like a
> > good idea one way or the other. Course, this meant a search of the PCP
> > lists or increasing the size of the PCP structure - swings and
> > roundabouts :/
>
> Maybe include those as well? Its good stuff.
>
It wasn't a clear win for this pass though. While conceptually it makes
sense, the increase in size of the PCP structure and the search cost
look nasty although they look better in comparison to taking the zone
lock and then lots of buddy split/merging.
I reckon it'll be high on the list for pass 2 though if pass 1 goes ok.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-03-20 16:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-20 10:02 [PATCH 00/25] Cleanup and optimise the page allocator V5 Mel Gorman
2009-03-20 10:02 ` [PATCH 01/25] Replace __alloc_pages_internal() with __alloc_pages_nodemask() Mel Gorman
2009-03-20 10:02 ` [PATCH 02/25] Do not sanity check order in the fast path Mel Gorman
2009-03-20 10:02 ` [PATCH 03/25] Do not check NUMA node ID when the caller knows the node is valid Mel Gorman
2009-03-20 10:02 ` [PATCH 04/25] Check only once if the zonelist is suitable for the allocation Mel Gorman
2009-03-20 10:02 ` [PATCH 05/25] Break up the allocator entry point into fast and slow paths Mel Gorman
2009-03-20 10:02 ` [PATCH 06/25] Move check for disabled anti-fragmentation out of fastpath Mel Gorman
2009-03-20 10:02 ` [PATCH 07/25] Check in advance if the zonelist needs additional filtering Mel Gorman
2009-03-20 15:04 ` Christoph Lameter
2009-03-20 10:02 ` [PATCH 08/25] Calculate the preferred zone for allocation only once Mel Gorman
2009-03-20 15:06 ` Christoph Lameter
2009-03-20 15:29 ` Mel Gorman
2009-03-20 10:02 ` [PATCH 09/25] Calculate the migratetype " Mel Gorman
2009-03-20 15:08 ` Christoph Lameter
2009-03-20 10:02 ` [PATCH 10/25] Calculate the alloc_flags " Mel Gorman
2009-03-20 10:02 ` [PATCH 11/25] Calculate the cold parameter " Mel Gorman
2009-03-20 15:09 ` Christoph Lameter
2009-04-21 15:13 ` Mel Gorman
2009-04-21 15:25 ` Christoph Lameter
2009-04-21 15:47 ` Mel Gorman
2009-03-20 10:02 ` [PATCH 12/25] Remove a branch by assuming __GFP_HIGH == ALLOC_HIGH Mel Gorman
2009-03-20 10:03 ` [PATCH 13/25] Inline __rmqueue_smallest() Mel Gorman
2009-03-20 10:03 ` [PATCH 14/25] Inline buffered_rmqueue() Mel Gorman
2009-03-20 10:03 ` [PATCH 15/25] Inline __rmqueue_fallback() Mel Gorman
2009-03-20 10:03 ` [PATCH 16/25] Save text by reducing call sites of __rmqueue() Mel Gorman
2009-03-20 10:03 ` [PATCH 17/25] Do not call get_pageblock_migratetype() more than necessary Mel Gorman
2009-03-20 10:03 ` [PATCH 18/25] Do not disable interrupts in free_page_mlock() Mel Gorman
2009-03-20 10:03 ` [PATCH 19/25] Do not setup zonelist cache when there is only one node Mel Gorman
2009-03-20 10:03 ` [PATCH 20/25] Do not check for compound pages during the page allocator sanity checks Mel Gorman
2009-03-20 10:03 ` [PATCH 21/25] Use allocation flags as an index to the zone watermark Mel Gorman
2009-03-20 10:03 ` [PATCH 22/25] Update NR_FREE_PAGES only as necessary Mel Gorman
2009-03-20 10:03 ` [PATCH 23/25] Get the pageblock migratetype without disabling interrupts Mel Gorman
2009-03-20 10:03 ` [PATCH 24/25] Re-sort GFP flags and fix whitespace alignment for easier reading Mel Gorman
2009-03-20 10:03 ` [PATCH 25/25] Use a pre-calculated value instead of num_online_nodes() in fast paths Mel Gorman
2009-03-20 15:00 ` [PATCH 00/25] Cleanup and optimise the page allocator V5 Christoph Lameter
2009-03-20 15:37 ` Mel Gorman
2009-03-20 16:04 ` Christoph Lameter
2009-03-20 16:41 ` Mel Gorman [this message]
2009-03-20 16:07 ` Christoph Lameter
2009-03-20 16:27 ` Mel Gorman
2009-03-20 19:43 ` Christoph Lameter
2009-03-23 11:52 ` Mel Gorman
2009-03-23 13:30 ` Christoph Lameter
2009-03-23 14:59 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090320164136.GQ24586@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ming.m.lin@intel.com \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).