[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1402171518080.25724@chino.kir.corp.google.com>
Date: Mon, 17 Feb 2014 15:23:16 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Luiz Capitulino <lcapitulino@...hat.com>
cc: Andrew Morton <akpm@...ux-foundation.org>, mtosatti@...hat.com,
Mel Gorman <mgorman@...e.de>,
Andrea Arcangeli <aarcange@...hat.com>,
Andi Kleen <andi@...stfloor.org>,
Rik van Riel <riel@...hat.com>, davidlohr@...com,
isimatu.yasuaki@...fujitsu.com, yinghai@...nel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists