lkml.org 
[lkml]   [2014]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?


\
 
 \ /
  Last update: 2014-02-21 23:21    [W:0.235 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site