On 10.04.2008 [17:15:37 -0500], Dean Luick wrote:
> This patch makes the morecore.c WARNING messages more user friendly
> and informative for those not turning on the debug messages. The
> most significant of these changes is a print of the number of huge
> pages requested when a request fails.
>
> Signed-off-by: Dean Luick <[EMAIL PROTECTED]> on behalf of Cray Inc.
> ---
> I have tested this on x86_64.
>
> Dean Luick
> Cray Inc.
>
>
> morecore.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
>
> diff -ruNp libhugetlbfs-dev-20080319/morecore.c
> libhugetlbfs-dev-20080319.modified2/morecore.c
> --- libhugetlbfs-dev-20080319/morecore.c 2008-03-19 10:25:28.000000000
> -0500
> +++ libhugetlbfs-dev-20080319.modified2/morecore.c 2008-04-10
> 11:39:54.000000000 -0500
> @@ -102,7 +102,8 @@ static void *hugetlbfs_morecore(ptrdiff_
> p = mmap(heapbase + mapsize, delta, PROT_READ|PROT_WRITE,
> MAP_PRIVATE, heap_fd, mapsize);
> if (p == MAP_FAILED) {
> - WARNING("Mapping failed in hugetlbfs_morecore()\n");
> + WARNING("New heap segment map at %p failed: %s\n",
> + heapbase+mapsize, strerror(errno));
> return NULL;
> }
>
> @@ -119,7 +120,7 @@ static void *hugetlbfs_morecore(ptrdiff_
> } else if (p != (heapbase + mapsize)) {
> /* Couldn't get the mapping where we wanted */
> munmap(p, delta);
> - WARNING("Mapped at %p instead of %p in
> hugetlbfs_morecore()\n",
> + WARNING("New heap segment mapped at %p instead of %p\n",
> p, heapbase + mapsize);
> if (__hugetlbfs_debug)
> dump_proc_pid_maps();
> @@ -151,8 +152,8 @@ static void *hugetlbfs_morecore(ptrdiff_
> if (ret != i) {
> DEBUG("Got %d of %d requested; err=%d\n", ret,
> i, ret < 0 ? errno : 0);
> - WARNING("Failed to reserve huge pages in "
> - "hugetlbfs_morecore()\n");
> + WARNING("Failed to allocate %ld huge pages "
> + "for heap\n", delta/blocksize);
I'd prefer to keep the reserve terminology here. It indicates a
fairly well-defined failpoint. So simply s/allocate/reserve/ in your
line.
Technically speaking, heap is also inaccurate. It's really for any
dynamic allocation, not necessarily just for the heap.
> munmap(p, delta);
> return NULL;
> }
> @@ -164,7 +165,7 @@ static void *hugetlbfs_morecore(ptrdiff_
> /* shrinking the heap */
>
> if (!mapsize) {
> - WARNING("Can't shrink empty heap!");
> + WARNING("Can't shrink empty heap!\n");
> return NULL;
> }
>
> @@ -188,7 +189,7 @@ static void *hugetlbfs_morecore(ptrdiff_
> heapbase + mapsize + delta);
> ret = munmap(heapbase + mapsize + delta, -delta);
> if (ret) {
> - WARNING("Unmapping failed in hugetlbfs_morecore(): "
> + WARNING("Heap shrink unmapping failed: "
> "%s\n", strerror(errno));
> } else {
>
> @@ -198,9 +199,8 @@ static void *hugetlbfs_morecore(ptrdiff_
> mapsize += delta;
> ret = ftruncate(heap_fd, mapsize);
> if (ret) {
> - WARNING("Couldn't truncate hugetlbfs file in "
> - "hugetlbfs_morecore(): %s\n",
> - strerror(errno));
> + WARNING("Couldn't truncate hugetlbfs file for"
> + " heap shrink: %s\n", strerror(errno));
I think these last two can still be phrased better.
How about:
"Unmapping failed while shriking heap: "
and
"Could not truncate hugetlbfs file to shrink heap: "
?
Thanks,
Nish
--
Nishanth Aravamudan <[EMAIL PROTECTED]>
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
