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.1402210158400.17851@chino.kir.corp.google.com>
Date:	Fri, 21 Feb 2014 02:07:08 -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:

> > 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.
> 
> There are a number of kernel command line parameters which can be
> modified in runtime as well.
> 

We could also make the kernel command line implement a shell scripting 
language of your choice.  There's no technical objection to it, of course 
you can do it, but is it in the interest of the kernel in terms of 
maintainability?

> You are asking what is the use-case.
> 

I'm asking what the use case is because it's still not explained.  You say 
a customer wants 8 1GB hugepages on node 0 on a 32GB machine.  Perfectly 
understandable.  The only thing missing, and is practically begging to be 
answered in this thread, is why must it be done on the command line?  That 
would be the justification for the patchset.  Andrew asked for Luiz to 
elaborate originally and even today the use case is not well described.

If you're asking for a maintenance burden to be accepted forever, it seems 
like as part of your due diligence that you would show why it must be done 
that way.  Being the easiest or "pragmatic" is not it, there is a much 
larger set of people who would be interested in dynamic allocation, myself 
and Google included.

> A particular distribution is irrelevant. What you want is a non default
> distribution of 1GB hugepages.
> 
> Can you agree with that ? (forget about particular values, please).
> 

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?
--
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/