On Tue, 2008-10-07 at 00:14 +0100, Mel Gorman wrote:
> On (06/10/08 17:02), Adam Litke didst pronounce:
> > On Mon, 2008-10-06 at 14:59 +0100, Mel Gorman wrote:
> > > On (03/10/08 18:36), Andy Whitcroft didst pronounce:
> > > > From: Adam Litke <[EMAIL PROTECTED]>
> > > > 
> > > > This patch fixes two intertwined issues:
> > > > 
> > > > When the SHM_HUGETLB flag is passed to shmget(), the system default 
> > > > huge page
> > > > size is used to back the shared memory segment.  Unlike with mmap() 
> > > > there is
> > > > not yet a way to use an alternate huge page size for shared memory 
> > > > segments.
> > > > This exception must be taken into account by the shmget override 
> > > > function -- it
> > > > cannot call gethugepagesize() but must discover the effective huge page 
> > > > size by
> > > 
> > > hmm, gethugepagesize() is an exported function in the lds file. Should
> > > we not be preserving it for backwards-compatability?
> > 
> > Not really sure what you're getting at here.  We haven't disabled
> > gethugepagesize() in any way.  We simply cannot use it for shm because
> > it will return the wrong answer in cases where the user attempts to
> > change the libhugetlbfs default page size to a size other then the
> > kernel's default size (eg. HUGETLB_DEFAULT_PAGE_SIZE, or when
> > libhugetlbfs doesn't find a mount point for the system default huge page
> > size).
> > 
> 
> Ok, now I understand. The semantics has changed from what I was expecting. I
> expected gethugepagesize() to be returning the system default hugepage
> size. But it's really returning the default hugepage size to use. As it
> is unlikely we have users of the API due to the header not being
> installed, it's fine. However, if the semantics were that it returned
> the system default huge pagesize, maybe we wouldn't need to have this
> duplicate proc readinfo?

Right, but then we'd need to duplicate the environment variable and
mount point availability checks in all those other places where the
libhugetlbfs default huge page size might not be the same as the system
default.  This default page size stuff is tricky business but from an
API perspective you have two ways to specify a huge page size: 1) Let
libhugetlbfs pick the size (and use gethugepagesize() to determine what
that size is), or 2) Specify explicit sizes for things where you really
care.  I think this is the sanest way of handling this complexity in a
user-friendly manner.

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to