Hi, 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 ) 2. Should the balloon driver be made capable of inflating/deflating the balloon automatically or only manually by using xm mem-set? 3. The guest OS balloon driver will have to be modified, will any modifications to xen(dom0) be required? 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? 5. What is the current state of the balloon driver? 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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@lists.xensource.com http://lists.xensource.com/xen-devel
hi I have used balloon driver in xen,and I am confused about the meaning of "Improve interaction between balloon driver and page allocator to avoid memory crunch."in the roadmap,what does it mean exactly? does it mean to improve the performance of the balloon, or to add some other functionality ,or to make the guestos''s memory size adapted automatically,or something else? Thanks in advance Mark Williamson 写道:>> 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: >> >> 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. > >> 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 >> > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I have used balloon driver in xen,and I am confused about the meaning > of "Improve interaction between balloon driver and page > > allocator to avoid memory crunch."in the roadmap,what does it mean exactly? > does it mean to improve the performance of the balloon, or to add some > other functionality ,or to make the guestos''s memory size adapted > automatically,or something else?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. In this past, this has been known to cause the OOM killer to kick in when not strictly necessary and also has caused some issues with network IO when used in dom0. The balloon driver just allocates loads of memory, and this seems to sometimes make Linux think that memory is running out, rather than understanding that the domain has been resized. Ideally, we''d use some sort of memory hotplug interface to Linux to make the resizing explicit. 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel