From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org,
torvalds@linux-foundation.org
Cc: stable-review@kernel.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk, Lee.Schermerhorn@hp.com,
lee.schermerhorn@hp.com, ak@linux.intel.com, eric.whitney@hp.com,
mel@csn.ul.ie, rientjes@google.com, agl@us.ibm.com,
apw@canonical.com
Subject: [patch 9/9] hugetlb: restore interleaving of bootmem huge pages (2.6.31)
Date: Thu, 01 Oct 2009 16:16:42 -0700 [thread overview]
Message-ID: <20091001231805.791852583@mini.kroah.org> (raw)
In-Reply-To: <20091001231938.GA29593@kroah.com>
[-- Attachment #1: hugetlb-restore-interleaving-of-bootmem-huge-pages.patch --]
[-- Type: text/plain, Size: 2425 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Not upstream as it is fixed differently in .32
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>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>
Cc: Adam Litke <agl@us.ibm.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Eric Whitney <eric.whitney@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -983,6 +983,7 @@ __attribute__((weak)) int alloc_bootmem_
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
@@ -993,7 +994,6 @@ __attribute__((weak)) int alloc_bootmem_
if (m)
goto found;
}
- hstate_next_node(h);
nr_nodes--;
}
return 0;
next prev parent reply other threads:[~2009-10-01 23:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 23:19 [patch 0/9] 2.6.27.36-stable review Greg KH
2009-10-01 23:16 ` Greg KH
2009-10-01 23:16 ` [patch 1/9] fs: make sure data stored into inode is properly seen before unlocking new inode Greg KH
2009-10-01 23:16 ` [patch 2/9] p54usb: add Zcomax XG-705A usbid Greg KH
2009-10-01 23:16 ` [patch 3/9] enc28j60: fix RX buffer overflow Greg KH
2009-10-01 23:16 ` [patch 4/9] pcnet_cs: Fix misuse of the equality operator Greg KH
2009-10-01 23:16 ` [patch 5/9] Fix incorrect stable backport to bas_gigaset Greg KH
2009-10-01 23:16 ` [patch 6/9] net ax25: Fix signed comparison in the sockopt handler Greg KH
2009-10-01 23:16 ` [patch 7/9] net: Make the copy length in af_packet sockopt handler unsigned Greg KH
2009-10-01 23:16 ` [patch 8/9] netfilter: bridge: refcount fix Greg KH
2009-10-01 23:16 ` Greg KH [this message]
2009-10-02 17:49 ` [patch 10/09] mm: fix anonymous dirtying Greg KH
2009-10-02 17:50 ` [patch 11/09] mmap: avoid unnecessary anon_vma lock acquisition in vma_adjust() Greg KH
2009-10-02 17:50 ` [patch 0/9] 2.6.27.36-stable review Greg KH
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=20091001231805.791852583@mini.kroah.org \
--to=gregkh@suse.de \
--cc=Lee.Schermerhorn@hp.com \
--cc=agl@us.ibm.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--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-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.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