Re: [Libhugetlbfs-devel] [PATCH] Get a hugetlbfs fd for a specific page size
On Wed, 2008-09-10 at 11:11 +1000, David Gibson wrote:
> On Tue, Sep 09, 2008 at 08:20:28PM +, Adam Litke wrote:
> > Allow applications that program to the libhugetlbfs API to specify a page
> > size
> > when requesting a hugetlbfs fd. If the size is invalid or not configured,
> > an
> > error will be returned.
> >
> > Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
>
> [snip]
> > +int hugetlbfs_unlinked_fd_for_size(long page_size)
> > {
> > const char *path;
> > char name[PATH_MAX+1];
> > int fd;
> >
> > - path = hugetlbfs_find_path();
> > + if (page_size == 0)
> > + page_size = hpage_sizes[hpage_sizes_default_idx].pagesize;
> > +
> > + path = hugetlbfs_find_path_for_size(page_size);
>
> Can't you just pass page_size through here, even if it's zero.
> hugetlbfs_find_path_for_size() already knows how to look up the
> default page size.
You are absolutely correct. Thanks for the review.
--
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
[Libhugetlbfs-devel] [PATCH 3/3] Get a hugetlbfs fd for a specific page size (V2)
Allow applications that program to the libhugetlbfs API to specify a page size
when requesting a hugetlbfs fd. If the size is invalid or not configured, an
error will be returned.
Changes since V1:
- Removed redundant handling when pagesize argument is zero
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
hugetlbfs.h |2 ++
hugeutils.c | 32 +---
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/hugetlbfs.h b/hugetlbfs.h
index 169e55f..d27ba6f 100644
--- a/hugetlbfs.h
+++ b/hugetlbfs.h
@@ -24,7 +24,9 @@
long gethugepagesize(void);
int hugetlbfs_test_path(const char *mount);
const char *hugetlbfs_find_path(void);
+const char *hugetlbfs_find_path_for_size(long page_size);
int hugetlbfs_unlinked_fd(void);
+int hugetlbfs_unlinked_fd_for_size(long page_size);
/* Diagnoses/debugging only functions */
long __lh_dump_proc_pid_maps(void);
diff --git a/hugeutils.c b/hugeutils.c
index 8a40640..4361a07 100644
--- a/hugeutils.c
+++ b/hugeutils.c
@@ -378,23 +378,36 @@ int hugetlbfs_test_path(const char *mount)
return (sb.f_type == HUGETLBFS_MAGIC);
}
-const char *hugetlbfs_find_path(void)
+const char *hugetlbfs_find_path_for_size(long page_size)
{
- char *path = hpage_sizes[hpage_sizes_default_idx].mount;
+ char *path;
+ int idx;
- if (strlen(path))
- return path;
+ if (page_size == 0)
+ idx = hpage_sizes_default_idx;
else
- return NULL;
+ idx = hpage_size_to_index(page_size);
+
+ if (idx >= 0) {
+ path = hpage_sizes[idx].mount;
+ if (strlen(path))
+ return path;
+ }
+ return NULL;
}
-int hugetlbfs_unlinked_fd(void)
+const char *hugetlbfs_find_path(void)
+{
+ return hugetlbfs_find_path_for_size(0);
+}
+
+int hugetlbfs_unlinked_fd_for_size(long page_size)
{
const char *path;
char name[PATH_MAX+1];
int fd;
- path = hugetlbfs_find_path();
+ path = hugetlbfs_find_path_for_size(page_size);
if (!path)
return -1;
@@ -416,6 +429,11 @@ int hugetlbfs_unlinked_fd(void)
return fd;
}
+int hugetlbfs_unlinked_fd(void)
+{
+ return hugetlbfs_unlinked_fd_for_size(0);
+}
+
#define IOV_LEN 64
int __lh_hugetlbfs_prefault(int fd, void *addr, size_t length)
{
-
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
[Libhugetlbfs-devel] [PATCH 2/3] Add new environment variable to specify the default hpage size to use
When multiple huge page sizes are available, libhugetlbfs behavior is to use
the huge page size reported in /proc/meminfo as the default size. Allow other
sizes to be used as the default via a new environment variable:
HUGETLB_DEFAULT_PAGE_SIZE. If this variable is specified, libhugetlbfs will
attempt to find a mounted filesystem of this size and use it as the default.
If this is unsuccessful, the first size that was found is used.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
---
hugeutils.c | 42 --
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/hugeutils.c b/hugeutils.c
index 4572001..8a40640 100644
--- a/hugeutils.c
+++ b/hugeutils.c
@@ -61,6 +61,33 @@ static int hpage_sizes_default_idx = -1;
#define BUF_SZ 256
#define MEMINFO_SIZE 2048
+static long parse_page_size(const char *str)
+{
+ char *pos;
+ unsigned long size;
+
+ size = strtoul(str, &pos, 0);
+ if (str == pos)
+ return -1;
+ /* Catch strtoul errors and sizes that overflow the native word size */
+ if (size > LONG_MAX)
+ return -1;
+
+ switch (*pos) {
+ case 'G':
+ case 'g':
+ size *= 1024;
+ case 'M':
+ case 'm':
+ size *= 1024;
+ case 'K':
+ case 'k':
+ size *= 1024;
+ }
+
+ return size;
+}
+
static long read_meminfo(const char *tag)
{
int fd;
@@ -138,6 +165,7 @@ static int hpage_size_to_index(unsigned long size)
static void probe_default_hpage_size(void)
{
+ char *env;
long size;
int index;
@@ -147,8 +175,18 @@ static void probe_default_hpage_size(void)
return;
}
- size = read_meminfo("Hugepagesize:");
- size *= 1024; /* convert from kB to B */
+ /*
+* Check if the user specified a default size, otherwise use the
+* system default size as reported by /proc/meminfo.
+*/
+ env = getenv("HUGETLB_DEFAULT_PAGE_SIZE");
+ if (env && strlen(env) > 0)
+ size = parse_page_size(env);
+ else {
+ size = read_meminfo("Hugepagesize:");
+ size *= 1024; /* convert from kB to B */
+ }
+
if (size >= 0) {
index = hpage_size_to_index(size);
if (index >= 0)
-
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
[Libhugetlbfs-devel] [PATCH 1/3] cleanup: Store page sizes in bytes
To avoid confusion, the library should store page sizes in bytes and library
interfaces should take page size parameters in bytes as well.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
---
hugeutils.c | 26 ++
libhugetlbfs_internal.h |2 +-
tests/hugetests.h |4 ++--
tests/testutils.c | 20 ++--
4 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/hugeutils.c b/hugeutils.c
index ce3391f..4572001 100644
--- a/hugeutils.c
+++ b/hugeutils.c
@@ -110,6 +110,7 @@ static long read_meminfo(const char *tag)
return val;
}
+/* Return the page size for the given mount point in bytes */
static long hugetlbfs_test_pagesize(const char *mount)
{
struct statfs64 sb;
@@ -122,7 +123,7 @@ static long hugetlbfs_test_pagesize(const char *mount)
if ((sb.f_bsize <= 0) || (sb.f_bsize > LONG_MAX))
return -1;
- return sb.f_bsize / 1024; /* Return in kB */
+ return sb.f_bsize;
}
static int hpage_size_to_index(unsigned long size)
@@ -130,7 +131,7 @@ static int hpage_size_to_index(unsigned long size)
int i;
for (i = 0; i < nr_hpage_sizes; i++)
- if (hpage_sizes[i].pagesize_kb == size)
+ if (hpage_sizes[i].pagesize == size)
return i;
return -1;
}
@@ -147,6 +148,7 @@ static void probe_default_hpage_size(void)
}
size = read_meminfo("Hugepagesize:");
+ size *= 1024; /* convert from kB to B */
if (size >= 0) {
index = hpage_size_to_index(size);
if (index >= 0)
@@ -190,7 +192,7 @@ static void add_hugetlbfs_mount(char *path, int user_mount)
}
idx = nr_hpage_sizes;
- hpage_sizes[nr_hpage_sizes++].pagesize_kb = size;
+ hpage_sizes[nr_hpage_sizes++].pagesize = size;
}
if (strlen(hpage_sizes[idx].mount)) {
@@ -210,7 +212,7 @@ static void debug_show_page_sizes(void)
DEBUG("Detected page sizes:\n");
for (i = 0; i < nr_hpage_sizes; i++)
DEBUG(" Size: %li kB %s Mount: %s\n",
- hpage_sizes[i].pagesize_kb,
+ hpage_sizes[i].pagesize / 1024,
i == hpage_sizes_default_idx ? "(default)" : "",
hpage_sizes[i].mount);
}
@@ -310,8 +312,7 @@ void __lh_setup_mounts(void)
*/
long gethugepagesize(void)
{
- long hpage_kb;
- long max_hpage_kb = LONG_MAX / 1024;
+ long hpage_size;
/* Are huge pages available and have they been initialized? */
if (hpage_sizes_default_idx == -1) {
@@ -319,16 +320,9 @@ long gethugepagesize(void)
return -1;
}
- hpage_kb = hpage_sizes[hpage_sizes_default_idx].pagesize_kb;
- if (hpage_kb > max_hpage_kb) {
- /* would overflow if converted to bytes */
- errno = hugepagesize_errno = EOVERFLOW;
- return -1;
- } else {
- errno = 0;
- /* convert from kb to bytes */
- return (1024 * hpage_kb);
- }
+ errno = 0;
+ hpage_size = hpage_sizes[hpage_sizes_default_idx].pagesize;
+ return hpage_size;
}
int hugetlbfs_test_path(const char *mount)
diff --git a/libhugetlbfs_internal.h b/libhugetlbfs_internal.h
index cf5f4fa..005aa21 100644
--- a/libhugetlbfs_internal.h
+++ b/libhugetlbfs_internal.h
@@ -81,7 +81,7 @@ extern int __lh_hugetlbfs_prefault(int fd, void *addr, size_t
length);
/* Multiple huge page size support */
struct hpage_size {
- unsigned long pagesize_kb;
+ unsigned long pagesize;
char mount[PATH_MAX+1];
};
diff --git a/tests/hugetests.h b/tests/hugetests.h
index 0afc00d..71a1e21 100644
--- a/tests/hugetests.h
+++ b/tests/hugetests.h
@@ -141,9 +141,9 @@ struct hugetlb_pool_counter_info_t {
char *sysfs_file;
};
extern struct hugetlb_pool_counter_info_t hugetlb_counter_info[];
-long get_pool_counter(unsigned int counter, unsigned long pagesize_kb);
+long get_pool_counter(unsigned int counter, unsigned long pagesize);
int set_pool_counter(unsigned int counter, unsigned long val,
- unsigned long pagesize_kb);
+ unsigned long pagesize);
int using_system_hpage_size(const char *mount);
diff --git a/tests/testutils.c b/tests/testutils.c
index 76ce860..172ce61 100644
--- a/tests/testutils.c
+++ b/tests/testutils.c
@@ -289,7 +289,7 @@ int file_write_ulong(char *file, unsigned long val)
return ret > 0 ? 0 : -1;
}
-int select_pool_counter(unsigned int counter, unsigned long pagesize_kb,
+int select_pool_counter(unsigned int counter, unsigned long pagesize,
char *filename, char **key)
{
long default_size;
@@ -318,12 +318,12 @@ int select_pool_counter(unsigned int counter,
Re: [Libhugetlbfs-devel] [PATCH 1/7] Basic support for multiple hugetlbfs mount points
On (27/08/08 18:34), Adam Litke didst pronounce:
> 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.
>
> Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
> ---
>
> hugeutils.c | 268
> ++-
> init.c |1
> libhugetlbfs_internal.h |8 +
> 3 files changed, 201 insertions(+), 76 deletions(-)
>
>
> diff --git a/hugeutils.c b/hugeutils.c
> index cc5113f..2d53941 100644
> --- a/hugeutils.c
> +++ b/hugeutils.c
> @@ -38,14 +38,21 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
>
> #include "libhugetlbfs_internal.h"
> #include "hugetlbfs.h"
>
> -static long hpage_size; /* = 0 */
> -static char htlb_mount[PATH_MAX+1]; /* = 0 */
> static int hugepagesize_errno; /* = 0 */
>
> +#define MAX_HPAGE_SIZES 10
> +struct hpage_size hpage_sizes[MAX_HPAGE_SIZES];
Pity this has to be static but I guess allocating in the library is
tricky.
Mount points could have lots of characteristics outside of the path. It could
have different permissions, quota and pagesize for example. Would it be best
to discover all of this information at once? Initially, libhugetlbfs could use
the information to determine if a mount point was suitable or not and later
deal with the situation where multiple mount points of the same pagesize exist.
> +static int nr_hpage_sizes;
> +static int hpage_sizes_default_idx = -1;
> +
> //
> /* Internal functions */
> //
> @@ -102,63 +109,113 @@ static long read_meminfo(const char *tag)
> return val;
> }
>
> -//
> -/* Library user visible functions */
> -//
> +static long hugetlbfs_test_pagesize(const char *mount)
> +{
This function name is confusing. Rename to get_mount_pagesize()
> + struct statfs64 sb;
> + int err;
>
> -/*
> - * returns:
> - * on success, size of a huge page in number of bytes
> - * on failure, -1
> - * errno set to ENOSYS if huge pages are not supported
> - * errno set to EOVERFLOW if huge page size would overflow return type
> - */
> -long gethugepagesize(void)
> + err = statfs64(mount, &sb);
> + if (err)
> + return -1;
> +
> + if ((sb.f_bsize <= 0) || (sb.f_bsize > LONG_MAX))
> + return -1;
> +
> + return sb.f_bsize / 1024; /* Return in kB */
> +}
> +
> +static int hpage_size_to_index(unsigned long size)
> {
> - long hpage_kb;
> - long max_hpage_kb = LONG_MAX / 1024;
> + int i;
> +
> + for (i = 0; i < nr_hpage_sizes; i++)
> + if (hpage_sizes[i].pagesize_kb == size)
> + return i;
> + return -1;
> +}
Maybe this is used later, but it appears in this patch that if you
mandated that the default pagesize be at index 0, then this function
becomes largely redundant. You can avoid double registering by just
having this loop at the call site. The existance of a function like this
implies we'll never handle the case where multiple mount points of the
same size exist.
> +
> +static void probe_default_hpage_size(void)
> +{
> + long size;
> + int index;
>
> - if (hpage_size) {
Re: [Libhugetlbfs-devel] [RFD] hugecfg: Proposed scope and interfaces
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
Re: [Libhugetlbfs-devel] [RFD] hugecfg: Proposed scope and interfaces
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-hu
Re: [Libhugetlbfs-devel] [RFD] hugecfg: Proposed scope and interfaces
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
> pe
Re: [Libhugetlbfs-devel] [PATCH 3/3] Get a hugetlbfs fd for a specific page size (V2)
On Wed, Sep 10, 2008 at 02:17:17PM +, Adam Litke wrote: > Allow applications that program to the libhugetlbfs API to specify a page size > when requesting a hugetlbfs fd. If the size is invalid or not configured, an > error will be returned. > > Changes since V1: > - Removed redundant handling when pagesize argument is zero > > Signed-off-by: Adam Litke <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- 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
