Message-ID: <20140221191055.GD19955@amt.cnet>
Date:	Fri, 21 Feb 2014 16:10:55 -0300
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	David Rientjes <rientjes@...gle.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, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
> 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.

It is explained. You deleted it while replying (feel free to ask for
more information there and it will be provided).

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

It does not have to be maintained forever. See 
27be457000211a6903968dfce06d5f73f051a217 for one or git log for many
commands which have been removed.

If it becomes a maintenance burden, it can be removed.

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

OK.

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

It must be done this way because:

1) its the only interface which is easily backportable.

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

And also, the existance of the command line interface does not interfere in
any way with the dynamic allocation in userspace (just as you can
allocate 2M pages via kernel command line _and_ allocate during
runtime).
--
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/

Powered by blists - more mailing lists