Re: [patch 13/18] hugetlb: support boot allocate different sizes

[Nishanth Aravamudan <nacc@us.ibm.com>]

On 23.05.2008 [08:04:39 +0200], Nick Piggin wrote:
> On Fri, May 23, 2008 at 07:36:41AM +0200, Nick Piggin wrote:
> > On Fri, Apr 25, 2008 at 11:40:41AM -0700, Nishanth Aravamudan wrote:
> > > 
> > > So, you made max_huge_pages an array of the same size as the hstates
> > > array, right?
> > > 
> > > So why can't we directly use h->max_huge_pagees everywhere, and *only*
> > > touch max_huge_pages in the sysctl path.
> > 
> > It's just to bring up the max_huge_pages array initially for the
> > sysctl read path. I guess the array could be built every time the
> > sysctl handler runs as another option... that might hide away a
> > bit of the ugliness into the sysctl code I suppose. I'll see how
> > it looks.
> 
> Hmm, I think we could get into problems with the issue of kernel
> parameter passing vs hstate setup, so things might get a bit fragile.
> I think it is robust at this point in time to retain the
> max_huge_pages array if the hugetlb vs arch hstate registration setup
> gets revamped, it might be something to look at, but I prefer to keep
> it rather than tinker at this point.

Sure and that's fair.

But I'm approaching it from the perspective that the multi-valued
sysctl will go away with the sysfs interface. So perhaps I'll do a
cleanup then.

Also, we will want to update the linux-mm.org wiki diagrams if we change
what states hugepages can be in and the meaning of any of them. I'm not
sure that is the case now, but it might be.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

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