Re: [Xen-devel] Balloon driver and oom-killer

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

I hope you don't mind, but I cc-ed this back to the list.  I figure that other 
folks might also be interested in a more detailed explanation since I was a 
little vague before!

> Thank you for your reply
> and I do not understand the meaning of "The balloon driver just
> allocates loads of memory,",what does it mean?

The way the balloon driver really works (at the moment) is to just allocate 
lots of memory.  Once it's allocated by the balloon driver, it can't be used 
by anything else.  The balloon driver can then safely return that memory to 
Xen, so the domain has been shrunk.  The kernel thinks that the balloon 
driver has allocated loads of memory, whereas actually that memory is not 
there anymore.  When you grow the domain again, the balloon driver retrieves 
memory from Xen, and then frees it back to the guest.  From the kernel's 
point of view, the balloon driver has just released some memory it's been 
using.

> and another one ," There have been some bad interactions with Linux's
> memory management code when using the balloon driver - particularly when
> using it aggressively to shrink a domain." ,then could you give me a
> more detailed explaination about it?

There have been cases in the past of the Linux memory management code getting 
upset by the balloon driver.  From the kernel's point of view if you shrink a 
domain from 256M to 32M it looks like some kind of serious memory crunch is 
happening, with too many things requesting allocations.

This has been known to cause the Linux Out Of Memory (OOM) killer to come and 
destroy processes in order to free RAM - not good.  This can happen if you 
shrink a domain so much that it doesn't have enough RAM for all its processes 
anymore.  But it certainly used to happen even when there was enough RAM for 
the guest to keep operating, because the guest didn't understand what was 
happening.

I believe this is been mitigated by modifications to the balloon driver which 
cause it to allocate memory more gradually when shrinking the domain, giving 
the guest a chance to cope.  I don't know how much of a problem this is these 
days.

Anyhow, that's the basic idea of what's gone wrong in the past.  To be honest, 
I'm not sure how much of a problem these things are now or whether there's 
anything else the roadmap had in mind to improve.  It would certainly be 
cleaner if the ballooning operation could appear as a memory hotplug rather 
than just a lot of allocations; I don't know if that solves any of the memory 
crunch problems though (or how much of a problem these turn out to be 
nowadays).

I do think that if you don't fancy hacking on the balloon driver mechanism 
itself, a daemon to automatically redistribute memory to the domains which 
need it (by using the balloon drivers) could be a cool project and 
potentially useful.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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