On Wed, Nov 12, 2008 at 12:31:24PM +0000, Mel Gorman wrote:
> On Tue, Nov 11, 2008 at 10:42:02PM +1100, David Gibson wrote:
> > On Mon, Nov 10, 2008 at 11:55:30AM +0000, Mel Gorman wrote:
> > > There has been some disagreement on what the exact purpose of
> > > get_huge_pages()
> > > is. It was felt that the interface name implied that it dealt strictly
> > > with
> > > hugepages. This was reinforced by the fact in 2.0 that the length
> > > parameter
> > > had to be hugepage-aligned and that in 2.1-preX allocations were allowed
> > > to fall back to base pages. This led to resistance when the scope of the
> > > function was expanded further to include cache coloring.
> > >
> > > Rather than fighting endlessly, this patch series starts by enforcing that
> > > get_huge_pages() is a low-level interface dealing exclusively with huge
> > > pages. It no longer allows fallback and instead GHP_ flags in the future
> > > will determine what size of hugepages should be used - e.g. GHP_LARGEST.
> > >
> > > The patch then adds a new API called get_hugepage_region() that is
> > > intended
> > > to be vaguely malloc-like for the allocation of regions of memory that are
> > > backed by hugepages where possible. It is not responsible for doing
> > > packing
> > > like a true malloc-like interface would but it allows an unaligned length
> > > and fallback to base pages. The last patch adds support for coloring
> > > buffers
> > > allocated by get_hugepage_region().
> >
> > Hrm. Since it is more-or-less malloc() like, why not just
> > hugepage_alloc()?
>
> Because I do not want the callers to assume packing is happening. For
> example, I don't want some guy to be calling hugepage_alloc() with small
> sizes and then wondering why so much memory is being wasted.
Yeah, good point. Fair enough.
> > I realise we don't want to write a full allocator any time soon, but
> > it seems to me wise not to preclude (in our documentation, or
> > elsewhere) extending this interface to a full allocator. Indeed, I
> > believe the interface now is such that the innards could be changed to
> > a full hugepage-backed allocator which does do packing and all the
> > rest, without breaking users.
>
> Possibly, but the initial interface I wanted to be suitable for people
> writing an allocator on top of it, not wiring an allocator into
> libhugetlbfs.
>
> > Or to look at it another way, it *is* a full hugepage malloc()
> > implementation. It's just that this initial version isn't a very good
> > implementationm, at least for space-efficiency. We can fix this
> > deficiency later, if anyone cares enough, without altering the
> > interface.
>
> I think too many people would make the mistake thinking this version
> supporting packing if it was called hugepage_alloc(). If we really want
> to implement a proper allocator later, I think hugepage_alloc() would be
> a good name for it.
Ok.
--
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
