[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] memory_reservation bug?


  • To: xen-devel-list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Superficially this trace suggests a bug in the memory-reservation code:

Bootstrapping...
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?

Mick


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.