On (26/06/08 10:22), David Gibson didst pronounce: > On Wed, Jun 25, 2008 at 09:47:25PM +0100, 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. > > > > 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. > > > > Ideally, this or something like it would be merged for > > 2.0. Comments? > > I like the concept - I've vaguely thought we should implement > something like this for a while. > > Don't like the names. Since it's not a malloc() replacement, I don't > think it should be called "something_malloc()". I'd suggest > get_huge_pages() instead - that also works for the name of your flags > variable, in analogy with the kernel's get_free_pages() (which is > where the GFP_ prefix comes from). >
I hate naming things. I'm vaguely unhappy with get_huge_pages() and I have no idea why - maybe because I think get has something to do with reference counts. However, it fits better with the GHP_ prefix so I'll use it. > Also you define a one GHP_ flag, but your allocate function never > actually looks at the flags argument. > No because the default behaviour is that. At the moment, I have /* * Direct alloc flags and types * * GHP_FORCELARGE - Returns NULL if a huge page cannot be allocated * GFP_DEFAULT - Use a combination of flags deemed to be a sensible * default * by the current implementation of the library */ typedef unsigned long ghp_t; #define GHP_FORCELARGE 0x01UL #define GHP_DEFAULT (GFP_FORCELARGE) with the expectation people will use GHP_DEFAULT unless they have a good reason not to. I wanted to have the flags part of the signature for future expansion. Is that sensible? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ------------------------------------------------------------------------- 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
