linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	mtosatti@redhat.com, mgorman@suse.de, aarcange@redhat.com,
	andi@firstfloor.org, riel@redhat.com
Subject: Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
Date: Tue, 11 Feb 2014 10:10:27 -0500	[thread overview]
Message-ID: <20140211101027.5e32f1c2@redhat.com> (raw)
In-Reply-To: <20140210151354.68fe414f81335d4ce0e4c550@linux-foundation.org>

On Mon, 10 Feb 2014 15:13:54 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 10 Feb 2014 12:27:44 -0500 Luiz Capitulino <lcapitulino@redhat.com> 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.
> 
> Grumble.  "can be undesirable" is the entire reason for the entire
> patchset.  We need far, far more detail than can be conveyed in three
> words, please!

Right, sorry for that. I'll improve this for v2, but a better introduction
for the series would be something like the following.

Today, HugeTLB provides support for controlling allocation of persistent
huge pages on a NUMA system through sysfs. So, for example, if a sysadmin
wants to allocate 300 2M huge pages on node 1, s/he can do:

 echo 300 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

This works as long as you have enough contiguous pages, which may work
for 2M pages, but is harder for 1G huge pages. For those, it's better or even
required to reserve them at boot.

To this end we have the hugepages= command-line option, which works but misses
the per node control. This option evenly distributes huge pages among nodes.
However, we have users who want more flexibility. They want to be able to
specify something like: allocate 2 1G huge pages from node0 and 4 1G huge page
from node1. This is what this series implements.

It's basically per node allocation control for 1G huge pages, but it's
important to note that this series is not intrusive. All it does is to set
the initial per node allocation. All the functions and data structure added
by this series are only used once at boot, after that they are discarded and
rest in oblivion.

--
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>

  parent reply	other threads:[~2014-02-11 15:42 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 [this message]
2014-02-11  2:54 ` David Rientjes
2014-02-11  9:25   ` Mel Gorman
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=20140211101027.5e32f1c2@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mtosatti@redhat.com \
    --cc=riel@redhat.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).