From: Mel Gorman <mel@csn.ul.ie>
To: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
epasch@de.ibm.com, SCHILLIG@de.ibm.com,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
christof.schmitt@de.ibm.com, thoss@de.ibm.com, hare@suse.de,
npiggin@suse.de
Subject: Re: Performance regression in scsi sequential throughput (iozone) due to "e084b - page-allocator: preserve PFN ordering when __GFP_COLD is set"
Date: Mon, 8 Feb 2010 16:55:55 +0000 [thread overview]
Message-ID: <20100208165555.GD23680@csn.ul.ie> (raw)
In-Reply-To: <20100208152131.GC23680@csn.ul.ie>
> <SNIP>
> The prototype patch for avoiding congestion_wait is below. I'll start
> work on a fallback-to-other-percpu-lists patch.
>
And here is the prototype of the fallback-to-other-percpu-lists patch.
I'm afraid I've only managed to test it on qemu. My three test machines are
still occupied :(
==== CUT HERE ====
page allocator: Fallback to other per-cpu lists when the target list is empty and memory is low
When a per-cpu list of pages for a given migratetype is empty, the page
allocator is called to refill the PCP list. It's possible when memory
is low that this results in the process entering direct reclaim even
if it wasn't strictly necessary because there were pages free for other
migratetypes. Unconditionally falling back to other PCP lists hurts the
fragmentation-avoidance strategy which is also undesirable.
When the desired PCP list is empty, this patch checks how many free pages
there are on the PCP lists and if refilling the list could result in direct
reclaim. If direct reclaim is unlikely, the PCP list is refilled to maintain
fragmentation-avoidance. Otherwise, a page from an alternative PCP list is
chosen to maintain performance and avoid direct reclaim.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
mm/page_alloc.c | 37 ++++++++++++++++++++++++++++++++++---
1 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8deb9d0..009d683 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1168,6 +1168,39 @@ void split_page(struct page *page, unsigned int order)
set_page_refcounted(page + i);
}
+/* Decide whether to find an alternative PCP list or refill */
+static struct list_head *pcp_fallback(struct zone *zone,
+ struct per_cpu_pages *pcp,
+ int start_migratetype, int cold)
+{
+ int i;
+ int migratetype;
+ struct list_head *list;
+ long free_pages = zone_page_state(zone, NR_FREE_PAGES) - pcp->batch;
+
+ /*
+ * Find a PCPU list with free pages in the same order as
+ * fragmentation-avoidance fallback in the event that refilling
+ * the PCP list may result in direct reclaim
+ */
+ if (pcp->count && free_pages <= low_wmark_pages(zone)) {
+ for (i = 0; i < MIGRATE_PCPTYPES - 1; i++) {
+ migratetype = fallbacks[start_migratetype][i];
+ list = &pcp->lists[migratetype];
+
+ if (!list_empty(list))
+ return list;
+ }
+ }
+
+ /* Alternatively, we need to allocate more memory to the PCP lists */
+ list = &pcp->lists[start_migratetype];
+ pcp->count += rmqueue_bulk(zone, 0, pcp->batch, list,
+ migratetype, cold);
+
+ return list;
+}
+
/*
* Really, prep_compound_page() should be called from __rmqueue_bulk(). But
* we cheat by calling it from here, in the order > 0 path. Saves a branch
@@ -1193,9 +1226,7 @@ again:
list = &pcp->lists[migratetype];
local_irq_save(flags);
if (list_empty(list)) {
- pcp->count += rmqueue_bulk(zone, 0,
- pcp->batch, list,
- migratetype, cold);
+ list = pcp_fallback(zone, pcp, migratetype, cold);
if (unlikely(list_empty(list)))
goto failed;
}
next prev parent reply other threads:[~2010-02-08 16:56 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 14:39 Performance regression in scsi sequential throughput (iozone) due to "e084b - page-allocator: preserve PFN ordering when __GFP_COLD is set" Christian Ehrhardt
2009-12-07 15:09 ` Mel Gorman
2009-12-08 17:59 ` Christian Ehrhardt
2009-12-10 14:36 ` Christian Ehrhardt
2009-12-11 11:20 ` Mel Gorman
2009-12-11 14:47 ` Christian Ehrhardt
2009-12-18 13:38 ` Christian Ehrhardt
2009-12-18 17:42 ` Mel Gorman
2010-01-14 12:30 ` Christian Ehrhardt
2010-01-19 11:33 ` Mel Gorman
2010-02-05 15:51 ` Christian Ehrhardt
2010-02-05 17:49 ` Mel Gorman
2010-02-08 14:01 ` Christian Ehrhardt
2010-02-08 15:21 ` Mel Gorman
2010-02-08 16:55 ` Mel Gorman [this message]
2010-02-09 6:23 ` Christian Ehrhardt
2010-02-09 15:52 ` Christian Ehrhardt
2010-02-09 17:57 ` Mel Gorman
2010-02-11 16:11 ` Christian Ehrhardt
2010-02-12 10:05 ` Nick Piggin
2010-02-15 6:59 ` Nick Piggin
2010-02-15 15:46 ` Christian Ehrhardt
2010-02-16 11:25 ` Mel Gorman
2010-02-16 16:47 ` Christian Ehrhardt
2010-02-17 9:55 ` Christian Ehrhardt
2010-02-17 10:03 ` Christian Ehrhardt
2010-02-18 11:43 ` Mel Gorman
2010-02-18 16:09 ` Christian Ehrhardt
2010-02-19 11:19 ` Christian Ehrhardt
2010-02-19 15:19 ` Mel Gorman
2010-02-22 15:42 ` Christian Ehrhardt
2010-02-25 15:13 ` Christian Ehrhardt
2010-02-26 11:18 ` Nick Piggin
2010-03-02 6:52 ` Nick Piggin
2010-03-02 10:04 ` Mel Gorman
2010-03-02 10:36 ` Nick Piggin
2010-03-02 11:01 ` Mel Gorman
2010-03-02 11:18 ` Nick Piggin
2010-03-02 11:24 ` Mel Gorman
2010-03-03 6:51 ` Christian Ehrhardt
2010-02-08 15:02 ` Christian Ehrhardt
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=20100208165555.GD23680@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=SCHILLIG@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=christof.schmitt@de.ibm.com \
--cc=ehrhardt@linux.vnet.ibm.com \
--cc=epasch@de.ibm.com \
--cc=hare@suse.de \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=schwidefsky@de.ibm.com \
--cc=thoss@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.