On Thu, Jun 26, 2008 at 01:47:14AM +0100, Mel Gorman wrote:
> 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
Heh.. I know that feeling well.
> - 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.
Ok. And free_huge_pages() on the other side?
> > 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
Hrm. I think having the flags argument is a fairly good idea for
future expansion, but I don't think defining a do-nothing flag to
start with is sensible.
> /*
> * Direct alloc flags and types
> *
> * GHP_FORCELARGE - Returns NULL if a huge page cannot be allocated
In fact, on further reflection, I think this flag is silly anyway.
This whole interface is for explicitly managing hugepage allocations.
If we want fallback to non-hugepages, it belongs at a different level;
this function should always fail if it can't get hugepages.
> * 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?
Having the GHP_DEFAULT is sensible, yes. But just define it as 0, and
ditch the unuseful FORCELARGE flag.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
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
