linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	mtosatti@redhat.com, Mel Gorman <mgorman@suse.de>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>,
	davidlohr@hp.com, isimatu.yasuaki@jp.fujitsu.com,
	yinghai@kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option
Date: Mon, 17 Feb 2014 15:23:16 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.02.1402171518080.25724@chino.kir.corp.google.com> (raw)
In-Reply-To: <20140217085622.39b39cac@redhat.com>

On Mon, 17 Feb 2014, Luiz Capitulino wrote:

> hugepages= and hugepages_node= are similar, but have different semantics.
> 
> hugepagesz= and hugepages= create a pool of huge pages of the specified size.
> This means that the number of times you specify those options are limited by
> the number of different huge pages sizes an arch supports. For x86_64 for
> example, this limit is two so one would not specify those options more than
> two times. And this doesn't count default_hugepagesz=, which allows you to
> drop one hugepagesz= option.
> 
> hugepages_node= allows you to allocate huge pages per node, so the number of
> times you can specify this option is limited by the number of nodes. Also,
> hugepages_node= create the pools, if necessary (at least one will be). For
> this reason I think it makes a lot of sense to have different options.
> 

I understand you may want to add as much code as you can to the boot code 
so that you can parse all this information in short-form, and it's 
understood that it's possible to specify a different number of varying 
hugepage sizes on individual nodes, but let's come back down to reality 
here.

Lacking from your entire patchset is a specific example of what you want 
to do.  So I think we're all guessing what exactly your usecase is and we 
aren't getting any help.  Are you really suggesting that a customer wants 
to allocate 4 1GB hugepages on node 0, 12 2MB hugepages on node 0, 6 1GB 
hugepages on node 1, 24 2MB hugepages on node 1, 2 1GB hugepages on node 
2, 100 2MB hugepages on node 3, etc?  Please.

If that's actually the usecase then I'll renew my objection to the entire 
patchset and say you want to add the ability to dynamically allocate 1GB 
pages and free them at runtime early in initscripts.  If something is 
going to be added to init code in the kernel then it better be trivial 
since all this can be duplicated in userspace if you really want to be 
fussy about it.

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

  reply	other threads:[~2014-02-17 23:23 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14  1:02 [PATCH v2 0/4] " Luiz Capitulino
2014-02-14  1:02 ` [PATCH 1/4] memblock: memblock_virt_alloc_internal(): add __GFP_THISNODE flag support Luiz Capitulino
2014-02-14  1:02 ` [PATCH 2/4] memblock: add memblock_virt_alloc_nid_nopanic() Luiz Capitulino
2014-02-14  1:02 ` [PATCH 3/4] hugetlb: add parse_pagesize_str() Luiz Capitulino
2014-02-14  1:02 ` [PATCH 4/4] hugetlb: add hugepages_node= command-line option Luiz Capitulino
2014-02-14 23:14   ` David Rientjes
2014-02-15  3:58     ` Luiz Capitulino
2014-02-15 10:06       ` David Rientjes
2014-02-17 13:56         ` Luiz Capitulino
2014-02-17 23:23           ` David Rientjes [this message]
2014-02-18 12:30             ` Marcelo Tosatti
2014-02-18 22:16               ` David Rientjes
2014-02-20  2:22                 ` Marcelo Tosatti
2014-02-20  3:46                   ` David Rientjes
2014-02-20  4:42                     ` Luiz Capitulino
2014-02-20  4:51                       ` David Rientjes
2014-02-20 15:06                         ` Luiz Capitulino
2014-02-20 21:34                     ` Marcelo Tosatti
2014-02-20 23:15                       ` David Rientjes
2014-02-21  2:28                         ` Marcelo Tosatti
2014-02-21 10:07                           ` David Rientjes
2014-02-21 19:10                             ` Marcelo Tosatti
2014-02-21 22:04                               ` David Rientjes
2014-02-21 22:36                                 ` Andi Kleen
2014-02-21 22:44                                   ` David Rientjes
2014-02-21 22:55                                     ` Andi Kleen
2014-02-21  3:35                         ` Luiz Capitulino
2014-02-20 21:38                     ` Marcelo Tosatti
2014-02-20 23:17                       ` David Rientjes
2014-02-18  5:47         ` Davidlohr Bueso
2014-02-21 23:54           ` Andrew Morton
2014-02-22  4:03             ` Andi Kleen
2014-02-22  4:31               ` Davidlohr Bueso
2014-02-22  4:40               ` 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=alpine.DEB.2.02.1402171518080.25724@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=davidlohr@hp.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mtosatti@redhat.com \
    --cc=riel@redhat.com \
    --cc=yinghai@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