On Wed, Mar 09, 2016 at 07:39:18PM +0200, Michael S. Tsirkin wrote: > On Wed, Mar 09, 2016 at 08:04:39PM +0300, Roman Kagan wrote: > > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote: > > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote: > > > > For (1) I've been trying to make a point that skipping clean pages is > > > > much more likely to result in noticable benefit than free pages only. > > > > > > I guess when you say clean you mean zero? > > > > No I meant clean, i.e. those that could be evicted from RAM without > > causing I/O. > > They must be migrated unless guest actually evicts them. If the balloon is inflated the guest will. > It's not at all clear to me that it's always preferable > to drop all clean pages from pagecache. It is clearly is > going to slow the guest down significantly. That's a matter for optimization. The current value for /proc/meminfo:MemAvailable (which is being proposed as a member of balloon stats, too) is a conservative estimate which will probably cover a good deal of cases. > > I must be missing something obvious, but how is that different from > > inflating and then immediately deflating the balloon? > > It's exactly the same except > - we do not initiate this from host - it's guest doing > things for its own reasons > - a bit less guest/host interaction this way I don't quite understand why you need to deflate the balloon until the VM is on the destination host. deflate_on_oom will do it if the guest is really tight on memory; otherwise there appears to be no reason for it. But then inflation followed immediately by deflation doubles the guest/host interactions rather than reduces them, no? > > it's just the granularity that makes things slow and > > stands in the way. > > So we could request a specific page size/alignment from guest. > Send guest request to give us memory in aligned units of 2Mbytes, > and then host can treat each of these as a single huge page. I'd guess just coalescing contiguous pages would already speed things up. I'll try to find some time to experiment with it. Roman. -- 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
