Mel Gorman wrote: > HUGETLB_MORECORE currently exists to allow glibc to back malloc() with > large pages instead of small pages. However, not all applications use glibc > malloc() nor is it always desirable to back malloc() with huge pages. There > exists a requirement that a hugepage-aware application be able to allocate > hugepages directly. > It would be good to maintain an easy approach for letting the end user know
(a) what's completely transparent to an application (ie: environment variables) and (b) what approach to use for programming changes which would allow an application program/software vendor to directly access the huge pages The other example is to be able to transparently mix and match user applications, add-on's like MicroQuill's SmartHeap, and the huge pages. More customer flexibility without changing the underlying source code. The next step for an application programmer is making changes to the source code.. > Currently, each application is expected to discover the filesystem themselves, > mmap() the file and other house-keeping tasks. libhugetlbfs already implements > much of this complex logic internally. This patch exposes a simple API for the > allocation and freeing of regions backed by hugepages that applications > linking > directly to libhugetlbfs can use. The implementation is a little simplistic > but can be optimised later if and when applications perceive its performance > to be a bottleneck. The API itself should not need to change as a multi-page > aware API would be an additional rather than a replacement interface. > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
