[Xen-devel] Re: non-zero order allocations in shadow code may prevent live migration

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>Gosh.  Are you running with almost all memory in use and failing to
>allocate shadow memory?  Have you seen sh_set_allocation return -ENOMEM
>when there is enough memory on the page allocator's free lists?  Xend's
>ballooning rules have been wrong more than once before, and are what I'd
>suspect first.

Yes, that's the scenario (64G physical memory, one PV domain started with 4G
assigned, live migration back and forth between two hosts, perhaps intertwined
with other domain creation activities, plus perhaps ballooning Dom0 back up 
after
domain termination). So no, I verified there's about 21M free (xm info) before
migration starts (or after it failed), and the tools estimate the need 
correctly:

DEBUG (balloon:146) Balloon: 21888 KiB free; need 21504; done.

while shadow still fails (some of the messages might be temporary debugging
aids of ours):

(XEN) sh error: set_sh_allocation(): current 0 target 4608
(XEN) sh error: set_sh_allocation(): failed to allocate shadow pages.
(XEN) sh error: set_sh_allocation(): current 4212 target 0
(XEN) sh error: shadow_one_bit_enable(): shadow_one_bit_enable() failed memory 
allocation
(XEN) sh error: shadow_log_dirty_enable(): shadow_log_dirty_enable() received 
(errno = -12) from shadow_one_bit_enabled()

4608 pages are just 18432k, so there is about 3M of fragmented and hence
unusable space.

So then I'll go ahead with implementing the described change (I'm actually
intending to have shadow_prealloc() take not just an order, but also a count
parameter - in a number of places it is being called with SHADOW_MAX_ORDER
for no reason other than wanting 3 or 4 single pages).

Jan


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