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. 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. > > Yea. In fact, one can zero out any number of pages > > quickly by putting them in balloon and immediately > > taking them out. > > > > Access will fault a zero page in, then COW kicks in. > > 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 > > We could have a new zero VQ (or some other option) > > to pass these pages guest to host, but this only > > works well if page size matches the host page size. > > I'm afraid I don't yet understand what kind of pages that would be and > how they are different from ballooned pages. > > I still tend to think that ballooning is a sensible solution to the > problem at hand; I think it is, too. This does not mean we can't improve things though. This patchset is reported to improve things, it should be split up so we improve them for everyone and not just one specific workload. > 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. > Roman. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
