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

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

On 24.05.2008 [00:45:49 +0200], Nick Piggin wrote:
> On Fri, May 23, 2008 at 01:32:28PM -0700, Nishanth Aravamudan wrote:
> > 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.
> 
> Yes, that could be one good way to keep the proc API unchanged -- move
> it over to sysfs and just put a "default" hugepagesz in proc.

I would be fine with that approach, and can make my sysfs patch apply at
the end or the middle (as a replacement) for your series to achieve it.
Andi, do you have any input here? Would also make keeping libhugetlbfs
backwards compatible easier, as meminfo's layout wouldn't change at all
and would still be the legacy/default page size.

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>