I occassionally see failures live migrating due to running out of memory in sh_set_allocation(). For example on a 4Gb machine with freely-balloonable dom0, the routine attempts to allocate 1536 pages of heap, and fails right at the end: (xVM) free 5dc total 5dc xenheap 21 total 40000 max 40000 (xVM) failed to allocate shadow pages from domheap This is a 64-bit guest on 64-bit host. I see this in xend.log: [2008-10-01 08:56:31 100921] DEBUG (XendDomainInfo:2121) overhead_kb is now 9216 [2008-10-01 08:56:31 100921] DEBUG (balloon:116) Balloon: 12216 KiB free; need 9216; done. (Note that I added an extra 1Mb on to the normal overhead_kb allocation). So we have 12Mb free from physinfo, and we''re trying to allocate 6Mb plus some other smaller allocations. I suspect the issue is one of fragmentation of the heap? That is, no allocations of order SHADOW_MAX_ORDER could be found? Does the linux balloon handler free in page-sized increments like Solaris currently does? Is there a better way to handle this? regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/10/08 17:17, "John Levon" <levon@movementarian.org> wrote:> So we have 12Mb free from physinfo, and we''re trying to allocate 6Mb plus some > other smaller allocations. I suspect the issue is one of fragmentation of the > heap? That is, no allocations of order SHADOW_MAX_ORDER could be found? > > Does the linux balloon handler free in page-sized increments like Solaris > currently does? > > Is there a better way to handle this?It''d be nice if the shadow code didn''t need order >0 allocations. I don''t know if that is likely to change, or how easy it would be, however. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel