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

[Nick Piggin <npiggin@suse.de>]

On Fri, May 23, 2008 at 01:39:08PM -0700, Nishanth Aravamudan wrote:
> 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).

Yes, I think that is a good plan.

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

Yes I have Jon's patches in my set now.

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