On Wed, 2008-09-10 at 19:47 +0100, Mel Gorman wrote: > 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?
It's analogous to hugectl and hugeedit. I'd prefer to stick to a standard naming convention (ie. huge*). > > > 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 Hmm, but according to the BSD manpage, the pagesize utility prints the base page size that would be returned by getpagesize(). So to really preserve compatibility, the Linux pagesize command should do this very same thing. Given that logic, then the pagesize command does not deal in huge page sizes and therefore doesn't belong with libhugetlbfs. > > * Display information about mounted hugetlbfs filesystems including: > > path, page size and quota > > and permissions. Sure. That's reasonable. > > > * 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. Yep, there should be a way to show pool statistics for a selected page size (possibly also for a selected numa node). > > > 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. Yep. This manpage for SunOS confirms that this call approaches this in a standard way. http://harley.mcnc.org/nmsweb/cgi-bin/man?getpagesizes+3C > > struct hugetlb_stat_pagesize { > > Rename to hpool_stat. hugetlb tells me nothing additional I've been prefixing with hugetlb to avoid namespace collisions since this would be an exported data type. > > 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. This would be the library interface that a program like hugecfg would use to fetch and display pool counter statistics. I suppose hugecfg could instead call get_pool_counter() several times in sequence. > > /* > > * 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. Namespace considerations apply here as well. But like above, we could perhaps use set_pool_counter(). These functions would simply be nice wrappers for non-libhugetlbfs programmers to use. > > > > 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 > > > -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ------------------------------------------------------------------------- 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
