linux-kernel - Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option

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.1402111951490.31912@chino.kir.corp.google.com>
Date:	Tue, 11 Feb 2014 19:59:40 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Luiz Capitulino <lcapitulino@...hat.com>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	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>
Subject: Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option

On Tue, 11 Feb 2014, Luiz Capitulino 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.
> > > 
> > 
> > And when hugepages can no longer be allocated on a node because it is too 
> > small, the remaining hugepages are distributed over nodes with memory 
> > available, correct?
> 
> No. hugepagesnid= tries to obey what was specified by the uses as much as
> possible.

I'm referring to what I quoted above, the hugepages= parameter.  I'm 
saying that using existing functionality you can reserve an excess of 
hugepages and then free unneeded hugepages at runtime to get the desired 
amount allocated only on a specific node.

> > Strange, it would seem better to just reserve as many hugepages as you 
> > want so that you get the desired number on each node and then free the 
> > ones you don't need at runtime.
> 
> You mean, for example, if I have a 2 node system and want 2 1G huge pages
> from node 1, then I have to allocate 4 1G huge pages and then free 2 pages
> on node 0 after boot? That seems very cumbersome to me. Besides, what if
> node0 needs this memory during boot?
> 

All of this functionality, including the current hugepages= reservation at 
boot, needs to show that it can't be done as late as when you could run an 
initscript to do the reservation at runtime and fragmentation is at its 
lowest level when userspace first becomes available.

I don't see any justification given in the patchset that suggests you 
can't simply do this in an initscript if it is possible to allocate 1GB 
pages at runtime.  If it's too late because of oom, then your userspace is 
going to oom anyway if you reserve the hugepages at boot; if it's too late 
because of fragmentation, let's work on that issue (and justification why 
things like movablecore= don't work for you).
--
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/