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@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/03/2009 17:32, "Mick Jordan" <Mick.Jordan@sun.com> wrote:> 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?Just because you called decrease_reservation() doesn''t mean the pages necessarily really got freed. If you still have mappings to them squirrelled away then the free can be deferred. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 03/11/09 11:08, Keir Fraser wrote:> On 11/03/2009 17:32, "Mick Jordan" <Mick.Jordan@sun.com> wrote: > > >> 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? >> > > Just because you called decrease_reservation() doesn''t mean the pages > necessarily really got freed. If you still have mappings to them squirrelled > away then the free can be deferred. >Ah, that explains it, thank you. I was taking the fact that the return value equaled the number I tried to decrease meant that it really did decrease by that amount. But, owing to a bug, I do in fact have mappings still lying around. Xen really does need a developer manual -;) Mick _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 03/11/09 11:08, Keir Fraser wrote:> > Just because you called decrease_reservation() doesn''t mean the pages > necessarily really got freed. If you still have mappings to them squirrelled > away then the free can be deferred. >A related question. I assume it is ok to have holes in the physical memory, i.e. call decrease_reservation with a range << max_pfn. In this case, what are the rules for the value in the P2M table? Does Xen zero out the slot or is it the guest''s responsibility? save/restore must be able to determine that a hole exists. Mick _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/03/2009 19:50, "Mick Jordan" <Mick.Jordan@sun.com> wrote:> A related question. I assume it is ok to have holes in the physical > memory, i.e. call decrease_reservation with a range << max_pfn. In this > case, what are the rules for the value in the P2M table? Does Xen zero > out the slot or is it the guest''s responsibility? save/restore must be > able to determine that a hole exists.The P2M is completely in your control. Xen doesn''t care about it. The toolstack cares about it only for save/restore -- there I think any invalid value stuffed in an empty slot would work just fine. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel