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]

Date:	Fri, 21 Feb 2014 14:04:03 -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 Fri, 21 Feb 2014, Marcelo Tosatti wrote:

> > 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?
> 
> It must be done this way because:
> 
> 1) its the only interface which is easily backportable.
> 

There's no pending patchset that adds dynamic allocation of GB hugepages 
so you can't comment on what is easily backportable and which isn't.

> 2) it improves the kernel command line interface from incomplete
> (lacking the ability to specify node<->page correlation), to 
> a complete interface.
> 

If GB hugepages can be allocated dynamically, I really think we should be 
able to remove hugepagesz= entirely for x86 after a few years of 
supporting it for backwards compatibility, even though Linus has insisted 
that we never break userspace in the past (which should discourage us 
from adding additional command line interfaces which are obsoleted in the 
future, such as in this case).

Still waiting on an answer to whether your customer would be able to 
dynamically allocate 1GB hugepages at runtime if we had such support and, 
if not, please show why not?
--
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/