lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ