[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> I'm working on the following topic from the xen roadmap as a part of an
> academic project: "Improve interaction between balloon driver and page
> allocator to avoid memory crunch."
>
> I have a few doubts regarding what exactly needs to be done:
>
>    1. Should the working of the balloon driver be same as in the case of
>    VMware ESX balloon driver? (
>    http://www.vmware.com/pdf/usenix_resource_mgmt.pdf )

The VMware balloon driver has some nice functionality (e.g. the way it 
automatically resizes VMs to try and balance memory usage efficiently).

>    2. Should the balloon driver be made capable of inflating/deflating
>    the balloon automatically or only manually by using xm mem-set?

An interesting enhancement would be to collect statistics from the domains 
about how much memory they require and modify their memory footprints 
accordingly.  This could be done by having domains communicate some kind of 
utilisation information to dom0 via Xenstore.  A daemon in dom0 would read 
out this information and periodically rebalance memory if appropriate (e.g. 
to give extra memory to a domain that's having a burst of activity).

This would be nice because (with appropriate safeguards to prevent a domain 
getting too big or small) it would help people "overcommit" domains on a 
single machine under the understanding that they're unlikely to all burst on 
memory usage at once.

This would require additional code in the guest (possibly in kernelspace) and 
a userspace daemon in dom0 which could just be written in C or Python.

>    3. The guest OS balloon driver will have to be modified, will any
>    modifications to xen(dom0) be required?

You can modify the balloon driver's operation without needing to change Xen or 
dom0.  But if you're adding new functionality then you may need to make that 
accessible from the Xenstore interface so that dom0 can activate it.

>    4. What exactly does the number of pages in high- and low-memory
>    balloons in the balloon_stats structure and in the output of cat
>    /proc/xen/balloon mean?

If I recall correctly, it records the amount of high and low memory that has 
been ballooned out at the current time.  Low memory is mapped and immediately 
addressable by the kernel; high memory must be temporarily mapped when the 
kernel needs to access it.  High memory exists on systems where there's too 
much RAM for the kernel to keep all of it mapped at once.

>    5. What is the current state of the balloon driver?

It works OK and quite a lot of people use it.  But there's room for 
improvement in the driver itself, and in making it easier and more flexible 
for people to use.

Cheers,
Mark

> Please correct me if my any of my assumptions are wrong. I'd be very
> grateful if someone could provide any information regarding this.
>
> Thanks,
> Ashutosh



-- 
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.