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. > 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. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ------------------------------------------------------------------------- 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
