linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	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: Fri, 21 Feb 2014 14:04:03 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.02.1402211358030.4682@chino.kir.corp.google.com> (raw)
In-Reply-To: <20140221191055.GD19955@amt.cnet>

On Fri, 21 Feb 2014, Marcelo Tosatti wrote:

> > I agree that your customer wants a non-default distribution of 1GB 
> > hugepages, yes, that's clear.  The questions that have not been answered: 
> > why must it be done this way as opposed to runtime?  If 1GB hugepages 
> > could be dynamically allocated, would your customer be able to use it?  If 
> > not, why not?  If dynamic allocation resolves all the issues, then is this 
> > patchset a needless maintenance burden if we had such support today?
> 
> It must be done this way because:
> 
> 1) its the only interface which is easily backportable.
> 

There's no pending patchset that adds dynamic allocation of GB hugepages 
so you can't comment on what is easily backportable and which isn't.

> 2) it improves the kernel command line interface from incomplete
> (lacking the ability to specify node<->page correlation), to 
> a complete interface.
> 

If GB hugepages can be allocated dynamically, I really think we should be 
able to remove hugepagesz= entirely for x86 after a few years of 
supporting it for backwards compatibility, even though Linus has insisted 
that we never break userspace in the past (which should discourage us 
from adding additional command line interfaces which are obsoleted in the 
future, such as in this case).

Still waiting on an answer to whether your customer would be able to 
dynamically allocate 1GB hugepages at runtime if we had such support and, 
if not, please show why not?

--
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-21 22:04 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
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 [this message]
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.1402211358030.4682@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