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()?
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.
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.
--
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
