mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	stable <stable@kernel.org>, Andi Kleen <andi@firstfloor.org>,
	Mel Gorman <mel@csn.ul.ie>, David Rientjes <rientjes@google.com>,
	Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>,
	Eric Whitney <eric.whitney@hp.com>
Subject: [PATCH] hugetlb:  restore interleaving of bootmem huge pages
Date: Fri, 17 Jul 2009 15:49:14 -0400	[thread overview]
Message-ID: <1247860154.11565.45.camel@useless.americas.hpqcorp.net> (raw)

PATCH fix distribution of bootmem huge pages

Against: 2.6.31-rc3

For stable, applicable back through 2.6.27

[A version of this patch has been added to the -mm tree.  That patch
won't apply cleanly to mainline nor stable trees because of function
renaming.  This one should.]

I noticed that alloc_bootmem_huge_page() will only advance to the
next node on failure to allocate a huge page.  I asked about this
on linux-mm and linux-numa, cc'ing the usual huge page suspects.
Mel Gorman responded:

	I strongly suspect that the same node being used until allocation
	failure instead of round-robin is an oversight and not deliberate
	at all. It appears to be a side-effect of a fix made way back in
	commit 63b4613c3f0d4b724ba259dc6c201bb68b884e1a ["hugetlb: fix
	hugepage allocation with memoryless nodes"]. Prior to that patch
	it looked like allocations would always round-robin even when
	allocation was successful.

Andy Whitcroft countered that the existing behavior looked like Andi
Kleen's original implementation and suggested that we ask him.  We
did and Andy replied that his intention was to interleave the
allocations.  So, ...

This patch moves the advance of the hstate next node from which to
allocate up before the test for success of the attempted allocation.
This will unconditionally advance the next node from which to alloc,
interleaving successful allocations over the nodes with sufficient
contiguous memory, and skipping over nodes that fail the huge page
allocation attempt.

Note that alloc_bootmem_huge_page() will only be called for huge pages
of order > MAX_ORDER.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/hugetlb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.31-rc3-mmotm-090715-2057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc3-mmotm-090715-2057.orig/mm/hugetlb.c	2009-07-17 11:30:20.000000000 -0400
+++ linux-2.6.31-rc3-mmotm-090715-2057/mm/hugetlb.c	2009-07-17 11:37:30.000000000 -0400
@@ -1010,6 +1010,7 @@ int __weak alloc_bootmem_huge_page(struc
 				NODE_DATA(h->hugetlb_next_nid),
 				huge_page_size(h), huge_page_size(h), 0);
 
+		hstate_next_node(h);
 		if (addr) {
 			/*
 			 * Use the beginning of the huge page to store the
@@ -1019,7 +1020,6 @@ int __weak alloc_bootmem_huge_page(struc
 			m = addr;
 			goto found;
 		}
-		hstate_next_node(h);
 		nr_nodes--;
 	}
 	return 0;



             reply	other threads:[~2009-07-17 19:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-17 19:49 Lee Schermerhorn [this message]
2009-07-17 22:14 ` Andi Kleen
2009-09-03 20:33 ` [stable] " Greg KH
2009-09-08 10:32   ` Mel Gorman
2009-09-08 14:13     ` Lee Schermerhorn
2009-09-09 21:56       ` Andrew Morton

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=1247860154.11565.45.camel@useless.americas.hpqcorp.net \
    --to=lee.schermerhorn@hp.com \
    --cc=agl@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=apw@canonical.com \
    --cc=eric.whitney@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=rientjes@google.com \
    --cc=stable@kernel.org \
    /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

all inboxes | Powered by JetHome®