On (10/09/08 14:31), Adam Litke didst pronounce: > 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*). >
Fair point. > > > > > 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. > I'd be ok with that behaviour though for compatability reasons. By default, print the base pagesize. With -a, print all possible pagesizes. Maybe later add options to print the pagesize that would be used by shmem (-s) but to the user, I think the default pagesize may be of less relevance because they are using mount points. > > > * 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 > Perfect. > > > 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. > Ok, fair enough. > > > 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. > Again, fair enough but this should not be exported in the same way get_huge_pages() is for example. > > > /* > > > * 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 > > > > > > -- -- 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
