Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, 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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]