Re: [patch 17/18] x86: add hugepagesz option on 64-bit

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

On 23.05.2008 [07:41:33 +0200], Nick Piggin wrote:
> On Wed, Apr 30, 2008 at 01:48:41PM -0700, Nishanth Aravamudan wrote:
> > On 23.04.2008 [11:53:19 +1000], npiggin@suse.de wrote:
> > > Add an hugepagesz=... option similar to IA64, PPC etc. to x86-64.
> > > 
> > > This finally allows to select GB pages for hugetlbfs in x86 now
> > > that all the infrastructure is in place.
> > 
> > Another more basic question ... how do we plan on making these hugepages
> > available to applications. Obviously, an administrator can mount
> > hugetlbfs with pagesize=1G or whatever and then users (with appropriate
> > permissions) can mmap() files created therein. But what about
> > SHM_HUGETLB? It uses a private internal mount of hugetlbfs, which I
> > don't believe I saw a patch to add a pagesize= parameter for.
> > 
> > So SHM_HUGETLB will (for now) always get the "default" hugepagesize,
> > right, which should be the same as the legacy size? Given that an
> > architecture may support several hugepage sizes, I have't been able to
> > come up with a good way to extend shmget() to specify the preferred
> > hugepagesize when SHM_HUGETLB is specified. I think for libhugetlbfs
> > purposes, we will probably add another environment variable to control
> > that...
> 
> Good question. One thing I like to do in this patch is to make very
> minimal as possible API changes even if it means userspace doesn't get
> the full functionality in all corner cases like that.
> 
> This way we can get the core work in and stabilized, then can take
> more time to discuss the user apis.
> 
> For that matter, I'm almost inclined to submit the patchset with only
> allow one active hstate specified on the command line, and no changes
> to any sysctls... just to get the core code merged sooner ;) however
> it is very valueable for testing and proof of concept to allow
> multiple active hstates to be configured and run, so I think we have
> to have that at least in -mm.
> 
> We probably have a month or two before the next merge window, so we
> have enough time to think about api issues I hope.

I think your plan is sensible, and is certainly how I would approach
adding this support to mainline. That is, all of the core hstate
functionality can probably go upstream rather quickly, as it's
functionally equivalent (and should be easy to verify as such with
libhuge's tests on all supported architectures).

I'm also hoping that once your patches are re-posted and hit -mm, I can
send out my sysfs patch, after updating/testing it, and that could also
go into -mm, which might allow the meminfo and sysctl patches to be
dropped from the series. Depends on your perspective on those, I
suppose, and might also need some coordination with Andrew to make the
series build in the right order (so the sysfs patch can be dropped in,
in place of both of them).

Does that seem reasonable? Also, for -mm coordination, are you going to
pull Jon's patches into your set, then?

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>