On (07/10/08 12:50), Adam Litke didst pronounce: > 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.
Ok, that would lead to badness. > 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. > You convinced me. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ------------------------------------------------------------------------- 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
