Messages in this thread | | | Date | Thu, 13 May 2004 08:49:03 +0100 | From | Christoph Hellwig <> | Subject | Re: 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/
| |