Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933430AbcCIRFC (ORCPT ); Wed, 9 Mar 2016 12:05:02 -0500 Received: from mx2.parallels.com ([199.115.105.18]:53978 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932489AbcCIRE4 (ORCPT ); Wed, 9 Mar 2016 12:04:56 -0500 Date: Wed, 9 Mar 2016 20:04:39 +0300 From: Roman Kagan To: "Michael S. Tsirkin" CC: "Li, Liang Z" , "Dr. David Alan Gilbert" , "ehabkost@redhat.com" , "kvm@vger.kernel.org" , "quintela@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "rth@twiddle.net" , Subject: Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Message-ID: <20160309170438.GB9715@rkaganb.sw.ru> Mail-Followup-To: Roman Kagan , "Michael S. Tsirkin" , "Li, Liang Z" , "Dr. David Alan Gilbert" , "ehabkost@redhat.com" , "kvm@vger.kernel.org" , "quintela@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "rth@twiddle.net" , riel@redhat.com References: <20160304102346.GB2479@rkaganb.sw.ru> <20160304163246-mutt-send-email-mst@redhat.com> <20160305214748-mutt-send-email-mst@redhat.com> <20160307110852-mutt-send-email-mst@redhat.com> <20160309142851.GA9715@rkaganb.sw.ru> <20160309173017-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160309173017-mutt-send-email-mst@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH2.sw.swsoft.com (10.255.249.46) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1157 Lines: 31 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. > 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? > 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; it's just the granularity that makes things slow and stands in the way. Roman.