On (08/09/08 15:10), Adam Litke didst pronounce:
> With the arrival of recent kernel features (namely the dynamic pool and
> multiple huge page sizes), comes increased configuration complexity. To
> ease configuration for users, libhugetlbfs should provide a set of
> library interfaces and a configuration program (hugecfg) so that the
Minor nit but I'd prefer a name like hpoolcfg or hpagecfg as hugecfg is
a bit ambigious. huge what?
> system's hugetlb configuration can be easily displayed and modified.
>
> Please reply with your feedback on my design below...
>
> I have considered the following use cases for hugecfg:
>
> * List all page sizes supported by the running kernel on this system and
> indicate the default page size. Provide the pool counters for each size
> (including nr_overcommit_hugepages)
For compatability, this should be a separate utility called pagesize
where it prints the default pagesize with no parameters and all possible
pages suppoed by the kernel (not just what we have mounted) with
pagesize -a
> * Display information about mounted hugetlbfs filesystems including:
> path, page size and quota
and permissions.
> * For a given page size, set the total number of pages (nr_hugepages)
> * For a given page size, set the max number of pages
> (nr_overcommit_huge_pages)
>
Should also display the number of pages currently in use by pools.
> The above use cases in turn demand the following library API extensions:
>
> /*
> * Fill the array page_sizes[] with at most max_nr values corresponding
> * to the supported huge page sizes for this system and kernel.
> * Return the number of page sizes found or < 0 on error.
> */
> int gethugepagesizes(long page_sizes[], int max_nr);
>
For portability reasons, this should be modelled on the getpagesizes()
call that exists in other operating systems.
> struct hugetlb_stat_pagesize {
Rename to hpool_stat. hugetlb tells me nothing additional
> unsigned long nr_hugepages;
> unsigned long nr_overcommit_hugepages;
> unsigned long free_hugepages;
> unsigned long resv_hugepages;
> unsigned long surplus_hugepages;
> }
>
> /*
> * Populate the structure pointed to by stat with hugetlb pool counter
> * values for the specified page size.
> * Return 0 on success, other values to indicate an error.
> */
> int hugetlb_stat_pagesize(long pagesize, struct hugetlb_stat_pagesize *stat);
>
I don't see why such a thing would be externally visible.
> /*
> * Set, respectively, nr_hugepages and nr_overcommit_hugepages for the
> * specified page size.
> * Returns 0 if the setting was successful, other values to indicate an error.
> */
> int hugetlb_set_nr_hugepages(long pagesize, unsigned long nr_pages);
> int hugetlb_set_nr_overcommit_hugepages(long pagesize, unsigned long
> nr_pages);
>
hugetlb_ is again redundant in the name. it doesn't tell me anything.
>
> Implementing the hugecfg utility would then become an orchestration of
> libhugetlbfs API calls (except for mount point scanning which would
> probably be implemented standalone in hugecfg). I envision the
> following hugecfg command line usage:
>
> hugecfg [options]
> -S,--show-page-sizes - Show available page sizes and stats
> -M,--show-mounts - Show mounted hugetlb filesystems
> -p,--page-size - Operate on a specific page size
> -n,--set-nr-hugepages - Set nr_hugepages for a specific
> size
> -o,--set-nr-overcommit-hugepages - Set nr_overcommit_hugepages for a
> specific size
>
--
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
