On Sun December 13 2009, Avi Kivity wrote: > On 12/12/2009 10:37 PM, Thomas Fjellstrom wrote: > > I have the opposite happen, when a VM is started, RES is usually lower > > than -m, which I find slightly odd. But makes sense if qemu/kvm don't > > actually allocate memory from the host till its requested the first > > time > > That is the case. > > > (if only it > > would return some of it afterwards, it would be even better). > > Use the balloon driver to return memory to the host. Will it actually just free the memory and leave the total memory size in the VM alone? Last I checked it would just decrease the total memory size, which isn't that useful. Sometimes it needs more ram, so its given 512M ram, but most of the time can live on 100M or so. > > I just fully shut down and restarted on of my vms, which is set to use > > 128-256 MB ram max. RES is like 72MB on start, and VIRT is 454M. RES > > generally gets up around 120MB ram when its doing something. > > > > One thing I do find a little odd is one of my VMs which is allocated > > 512MB ram, has a VIRT of 826MB ram. I didn't realize that qemu had so > > many lib dependencies. > > It's not just libraries, it's mostly glibc malloc() allocating huge > pools per thread, as well as large thread stacks. > > > Due to kvm not supporting giving memory back, besides by > > swapping large portions of unused guest ram, my host currently has over > > 1G used swap. Not particularly happy with that, but it doesn't seem to > > effect performance too much (except that it generally likes to swap > > host processes first, guest performance is decent, but host, not so > > much). > > The Linux vm prefers anonymous memory, so guests do get an advantage. > I think the only thing I'd like to have now is automatic memory return, much like vmware server has. It doesn't change what the guest VM sees, it just flushes the unused ram back to the host. -- Thomas Fjellstrom tfjellstrom@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
