lkml.org 
[lkml]   [2004]   [May]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 13 May 2004 08:49:03 +0100
FromChristoph Hellwig <>
SubjectRe: More convenient way to grab hugepage memory
On Thu, May 13, 2004 at 03:55:20PM +1000, David Gibson wrote:
> Andrew, please apply:
> 
> At present, getting a block of (quasi-) anonymous memory mapping with
> hugepages is a slightly convoluted process, involving creating a dummy
> file in a hugetlbfs filesystem.  In particular that means finding
> where such a filesystem is mounted, for which there is no standard
> mechanism.  Getting hugepage SysV shm segments is easier, just requing
> the SHM_HUGETLB flag.  This patch adds an analagous MAP_HUGETLB mmap()
> flag to easily request that a block of anonymous memory come from
> hugepages.
> 
> [The MAP_HUGETLB flag has the side effect that MAP_SHARED semantics
> will apply, even if MAP_PRIVATE is specific - but that's no different
> to explicitly mapping hugetlbfs].

Please don't do this.  It's messing all over sensitive codepathes in the
kernel, creating special cases and bloat of what you could with simple a
simpe hugetlb_mmap() wrapper ala (pseudocode)

hugetlb_mmap()
{
	fd = open(file in hugetlbfs)
	mmap(.., fd, ...)
	close(fd)
}
in some library.  The hugetlbfs implementation was chosen exactly because
if kept the impact of hugetlb pages down to normal kernel codepathes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [from the cache]
©2003-2008