On 30/11/10 03:51, Chu Rui wrote:
> George, I wonder why do you implement it as this? It looks better to
> used a resilient PoD cache, intead of a fixed one. Your wonderful work
> was appreciated, I just want to know your thought.
The main reason it was implemented this way was to make things
predictable for the toolstack. The XenServer control stack recently
implmented an automatic dynamic memory control functionality that would
allow you to simply set some ranges for memory, and it would
automatically change the ballooning for you. To do that effectively, it
needs to know how much memory is in use by every guest, and be able to
guarantee that a guest can get memory if it needs it. Furthermore,
XenServer has a High Availability (HA) option, which will allow you to
guarantee that if a given number of hosts go down, certain VMs can be
guaranteed to restart on other hosts. For both of these options, having
strong control of the memory is a necessity.
As I said in another e-mail, the Xen free page list is an
already-existing, system-wide pool from which VMs can (in theory)
allocate RAM. We could make it such that when a VM runs too low on PoD
memory, it pauses and notifies the toolstack somehow. A toolstack which
wanted to be more flexible with the balloon drivers could then increase
its PoD cache size from the free cache pool if available; if not
available, it could even create more free memory by ballooning down
other VMs. Xen doesn't need to be involved.
If you want to implement that functionality, I'm sure your patches would
be welcome. :-)
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home