Re: [PATCH] KVM simplified virtio balloon driver

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

 



Dor Laor wrote:
On Thu, 2008-01-17 at 07:56 -0600, Anthony Liguori wrote:
Dor Laor wrote:
On Thu, 2008-01-17 at 11:25 +0100, Martin Schwidefsky wrote:
Another idea: Martin added an oom notifier to the cmm driver. Before the oom-killer kicks in cmm will try to free 256 pages. I think your virtio balloon driver should do the same - it seems to be the correct tradeoff.
Nod, you definitly want to add an oom notifier. If 256 pages is the
correct number of pages to free is debatable. We have seen long delays
for a process that quickly eats up memory if there are lots of pages in
the balloon. The problem is that the memory management tries hard to
find memory until it decides to oom kill a process, only to be stopped
in the last second by the oom notifier. The 1MB is quickly eaten up
again so the whole things starts again. The profile of such a scenario
shows that almost all cpu is burned in the page reclaim code.

Seconded, in that case we can add a config space notification from the
guest to the host that will be triggered by the oom.
The host will get this notification and will decide whether to allow the
guest to deflate the balloon or to keep the current balloon size because
the whole host is over committed.
The host doesn't decide whether to allow the guest to deflate. Virtual memory size and resident memory side are independent in KVM. The host decides what the RSS is but the guest is free to determine it's VSS. The host provides hints to the guest about it's RSS size (via ballooning) so the guest can optimize it's VSS size. If guest chooses to make it's VSS size to large, it will only hurt itself (by being forced to swap by the host).

ok, this is true when the new memory controller targeted for the next
kernel.In that case I more then agree.
Nevertheless, the guest should pass the host data about it's current
memory usage (working set size, oom triggering, etc) so the host would change the rss limit dynamically.

What is the host going to do if the guest is OOMing? There is no way that the host can *verify* that the guest is OOMing so nothing prevents the guest from lying about the fact that it's OOMing in an attempt to get more memory.

More importantly though, the RSS limit has nothing to do with the guest OOMing. Reducing the guest's RSS limit will result in the guest swapping, not OOMing. Only the guest can prevent itself from OOMing by free'ing pages that were previously ballooned and that is what is being recommended here.

Regards,

Anthony Liguori

Thanks,
Dor


_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux