linux-kernel - Re: [PATCH 4/4] hugetlb: add hugepages

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.1402201502580.30647@chino.kir.corp.google.com>
Date:	Thu, 20 Feb 2014 15:15:46 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
cc:	Luiz Capitulino <lcapitulino@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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 Thu, 20 Feb 2014, Marcelo Tosatti wrote:

> Mel has clearly has no objection to the command line. You can also
> allocate 2M pages at runtime, and that is no reason for "hugepages="
> interface to not exist. 
> 

The "hugepages=" interface does exist and for good reason, when 
fragmentation is such that you cannot allocate that number of hugepages at 
runtime easily.  That's lacking from your use case: why can't your 
customer do it from an initscript?  So far, all you've said is that your 
customer wants 8 1GB hugepages on node 0 for a 32GB machine.

> There is a number of parameters that are modifiable via the kernel
> command line, so following your reasoning, they should all be removed,
> because it can be done at runtime.
> 

1GB is of such granularity that you'd typically either be (a) oom so that 
your userspace couldn't even start, or (b) have enough memory such that 
userspace would be able to start and allocate them dynamically through an 
initscript.

> Yes, we'd like to maintain backwards compatibility.
> 

Good, see below.

> > Thus, it seems, the easiest addition would have 
> > been "hugepagesnode=" which I've mentioned several times, there's no 
> > reason to implement yet another command line option purely as a shorthand 
> > which hugepage_node=1:2:1G is and in a very cryptic way.
> 
> Can you state your suggestion clearly (or point to such messages), and
> list the advantages of it versus the proposed patch ?
> 

My suggestion was posted on the same day this patchset was posted: 
http://marc.info/?l=linux-kernel&m=139241967514884 it would be helpful if 
you read the thread before asking for something that has been repeated 
over and over.

There's no need to implement a shorthand that combines a few kernel 
command line options.

That's not the issue, anymore, though, since there's no need for the 
patchset to begin with if you can dynamically allocate 1GB hugepages at 
runtime.  If your customer wanted 4096 2MB hugepages on node 0 instead of 
8 1GB hugepages on node 0, we'd not be having this conversation.

Do I really need to do your work for you and work on 1GB hugepages at 
runtime, which many more people would be interested in?  Or are we just 
seeking the easiest way out here with something that shuts the customer up 
and leaves a kernel command line option that we'll need to maintain to 
avoid breaking backwards compatibility in the future?
--
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/