From: Mel Gorman <mgorman@suse.de>
To: David Rientjes <rientjes@google.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
mtosatti@redhat.com, Andrea Arcangeli <aarcange@redhat.com>,
Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
Date: Tue, 11 Feb 2014 09:25:14 +0000 [thread overview]
Message-ID: <20140211092514.GH6732@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1402101851190.3447@chino.kir.corp.google.com>
On Mon, Feb 10, 2014 at 06:54:20PM -0800, David Rientjes wrote:
> On Mon, 10 Feb 2014, Luiz Capitulino wrote:
>
> > HugeTLB command-line option hugepages= allows the user to specify how many
> > huge pages should be allocated at boot. On NUMA systems, this argument
> > automatically distributes huge pages allocation among nodes, which can
> > be undesirable.
> >
>
> And when hugepages can no longer be allocated on a node because it is too
> small, the remaining hugepages are distributed over nodes with memory
> available, correct?
>
> > The hugepagesnid= option introduced by this commit allows the user
> > to specify which NUMA nodes should be used to allocate boot-time HugeTLB
> > pages. For example, hugepagesnid=0,2,2G will allocate two 2G huge pages
> > from node 0 only. More details on patch 3/4 and patch 4/4.
> >
>
> Strange, it would seem better to just reserve as many hugepages as you
> want so that you get the desired number on each node and then free the
> ones you don't need at runtime.
>
Or take a stab at allocating 1G pages at runtime. It would require
finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGES at
runtime. I would expect it would only work very early in the lifetime of
the system but if the user is willing to use kernel parameters to
allocate them then it should not be an issue.
--
Mel Gorman
SUSE Labs
--
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:[~2014-02-11 9:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 17:27 [PATCH 0/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 17:27 ` [PATCH 1/4] memblock: memblock_virt_alloc_internal(): alloc from specified node only Luiz Capitulino
2014-02-10 23:27 ` Andrew Morton
2014-02-11 9:20 ` Mel Gorman
2014-02-10 17:27 ` [PATCH 2/4] memblock: add memblock_virt_alloc_nid_nopanic() Luiz Capitulino
2014-02-10 17:27 ` [PATCH 3/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 23:27 ` Andrew Morton
2014-02-11 15:26 ` Luiz Capitulino
2014-02-12 3:44 ` Yasuaki Ishimatsu
2014-02-12 19:39 ` Luiz Capitulino
2014-02-10 17:27 ` [PATCH 4/4] hugetlb: hugepagesnid=: add 1G huge page support Luiz Capitulino
2014-02-10 23:30 ` Andrew Morton
2014-02-11 15:27 ` Luiz Capitulino
2014-02-10 17:55 ` [PATCH 0/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 23:13 ` Andrew Morton
2014-02-11 3:58 ` Davidlohr Bueso
2014-02-11 15:10 ` Luiz Capitulino
2014-02-11 2:54 ` David Rientjes
2014-02-11 9:25 ` Mel Gorman [this message]
2014-02-11 15:26 ` Marcelo Tosatti
2014-02-11 17:10 ` Mel Gorman
2014-02-11 20:15 ` Marcelo Tosatti
2014-02-12 10:39 ` Mel Gorman
2014-02-11 15:36 ` Luiz Capitulino
2014-02-12 3:59 ` David Rientjes
2014-02-12 20:09 ` Luiz Capitulino
2014-02-11 21:17 ` Andi Kleen
2014-02-11 21:31 ` Luiz Capitulino
2014-02-12 2:37 ` Andi Kleen
2014-02-12 4:01 ` David Rientjes
2014-02-12 19:33 ` Luiz Capitulino
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=20140211092514.GH6732@suse.de \
--to=mgorman@suse.de \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtosatti@redhat.com \
--cc=riel@redhat.com \
--cc=rientjes@google.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).