On Tue, Sep 02, 2008 at 08:54:02AM -0500, Adam Litke wrote:
> On Mon, 2008-09-01 at 15:45 +1000, David Gibson wrote:
> > On Fri, Aug 29, 2008 at 09:51:35AM -0500, Adam Litke wrote:
> > > On Fri, 2008-08-29 at 15:42 +1000, David Gibson wrote:
> > > > On Wed, Aug 27, 2008 at 06:34:41PM +0000, Adam Litke wrote:
> > [snip]
[snip]
> > > library/executable (akin to hugectl) that will be used to query page
> > > sizes, mount points, and pool counter values. Since we have adopted the
> >
> > Ok, but presumably there will also be library interface so that
> > programs can query this for themself?
>
> Yes, that's the plan.
Ok.
> > > limitation that only one mountpoint can exist per page size, I feel it
> > > is much more user-friendly to use the page size as a handle rather than
> > > the mount point. The page size is more important to the user than a
> > > filesystem mount point that we are actually trying to abstract away from
> > > them.
> >
> > Yes, that's true in general. But are there cases where multiple
> > mountpoints of the same page size aren't interchangable? The
> > mountpoints will have separate quota allocation, won't they? And they
> > could have different permissions.
>
> The only case I can imagine for needing two mountpoints of the same size
> in use by the same library at the same time is to accommodate a picky
> user who wants to account for morecore hugepages and ELF segment
> hugepages using different quotas for each type. While it's true that we
> could support such usage, I'm not sure it's worth the development effort
> at this stage.
Hrm. Yeah, true, all the cases I can think of for multiple
mountpoints of the same size have each mountpoint used by a different
program/library instance.
> If (farther down the road) we do decide we need this type of thing, we
> could add an interface for using mount handles akin to the following:
>
> /* Get a handle to a hugetlbfs mount point */
> hugetlbfs_mount_t *get_hugetlbfs(const char *path);
>
> /* Create an fd on a specific hugetlbfs mount point */
> int hugetlbfs_unlinked_fd_from_handle(hugetlbfs_mount_t *handle);
Yes. Well.. we could use this model for handling just the pagesizes
too, with the addition of a
hugetlbfs_mount_t *get_hugetlbfs_by_size(unsigned long pagesize);
Then using the returned handle for the unlinked_fd and get_huge_pages
functions.
> I think bringing this level of complexity to the environment variables
> (HUGETLB_MORECORE, HUGETLB_ELFMAP, etc) is not worth it given such a
> narrow and hypothetical use case.
True. Although using the get handle / pass handle model, handling
mountpoints individually isn't much more complex than just selecting
pagesize directly to the unlinked_fd/get_huge_pages functions. And it
would mean one less batch of entry points if we do ever need to do the
explicit mountpoint selection.
--
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
