This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] memory_reservation bug?

To: xen-devel-list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] memory_reservation bug?
From: Mick Jordan <Mick.Jordan@xxxxxxx>
Date: Wed, 11 Mar 2009 10:32:25 -0700
Delivery-date: Wed, 11 Mar 2009 10:32:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Reply-to: Mick.Jordan@xxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080807)
Superficially this trace suggests a bug in the memory-reservation code:

increase_reservation 155028 using 65536 .. returned 155028
increase_reservation 35596 using 220564 .. returned 35596
decrease_reservation 194384..256160 (61776) .. returned 61776
decrease_reservation 186634..194384 (7750) .. returned 7750
decrease_reservation 104935..186634 (81699) .. returned 81699
decrease_reservation 79981..104935 (24954) .. returned 24954
increase_reservation 122328 using 79981 (xVM) page_alloc.c:782:d172 Over-allocation for domain 172: 262145 > 262144 (xVM) memory.c:127:d172 Could not allocate order=0 extent: id=172 memflags=0 (5984 of 122328)
.. returned 5984

This is a domain starting with 256MB with maxmem at 1GB. The increase and decrease calls all return apparently correctly, but the final increase suggests that there is a miscounting of the allocated pages to the domain. This is Xen 3.1.4 and Solaris xVM (if that matters).

The "using" indicates where in the physmap the increase should occur and the range on the decrease is the pfns being given up.

I've looked at the code in memory.c and page_alloc.c and Xen certainly thinks tot_pages > max_pages for the domain when it reports the error.

The extent_order on the reservations is 0.

Any ideas?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>