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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>