On Wed, Aug 27, 2008 at 06:34:41PM +0000, Adam Litke wrote:
> An upcoming release of the Linux kernel will support simultaneous use of
> multiple huge page sizes. Each size will be accessed through its own
> specially-mounted hugetlbfs filesystem. The first step in enabling
> libhugetlbfs to support multiple simultaneous page sizes is enabling the
> support of multiple simultaneous hugetlbfs mount points.
>
> This patch adds basic support for multiple mount points while preserving
> backwards-compatibility. Mount points can be added via the HUGETLB_PATH
> environment variable which has been extended in the normal way to allow
> multiple paths to be specified (using a colon separator). Mounts will also be
> discovered by reading /proc/mounts or /etc/mtab. Up to 10 mount points are
> allowed to co-exist but only one mount per page size is allowed. If
> HUGETLB_PATH is specified, only mount points listed in that variable will be
> added. Otherwise, paths in /proc/mounts or /etc/mtab will be added in order
> of
> appearance. The first mount point of a given size is used and subsequent
> mounts of that page size are skipped.
>
> For compatibility and ease of use, a default mount point is selected. When
> multiple mount points have been added, /proc/meminfo is read to determine the
> system's default huge page size and the mount point having that size is
> selected as the default. If a mount point for the default page size cannot be
> found, the first mount point found becomes the default. The gethugepagesize()
> call has been modified to return the default huge page size as determined the
> method just described.
Hrm. Something about the structure of all this bothers me, but I'm
going to have to think some more on how I think it should be done. It
seems to me like this draft has too much of a dichotomy between the
default / non-default pagesize.
I'd envisage instead, something where the available mountpoints and
pagesizes can be queried. The functions for explicitly allocating
hugepages (unlinked_fd() and so forth) would have new versions which
take an explicit pagesize / mountpoint (not sure which). Obviously
the ones that just use a default pagesize would be kept too, for
compatibility but they'd just be a wrapper around the more general
version. Possibly a function to change the default pagesize (from
amongst the available ones) at runtime too. Like I say, need to
think about this some more.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
