| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Balloon driver and oom-killer
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
|
|
|
| |
|
Home