Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752138AbcCGGto (ORCPT ); Mon, 7 Mar 2016 01:49:44 -0500 Received: from mga02.intel.com ([134.134.136.20]:62129 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbcCGGti convert rfc822-to-8bit (ORCPT ); Mon, 7 Mar 2016 01:49:38 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,550,1449561600"; d="scan'208";a="928306485" From: "Li, Liang Z" To: "Michael S. Tsirkin" CC: Roman Kagan , "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 Thread-Topic: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Thread-Index: AQHRdTqPjTxTnYWKZEWM4lf/HjT6rZ9HeJiAgAEJK0D//+lWAIAAiTOQ//+bAoCAAMUSUP//hAyAABHVw1AAK0jMgABYA90w Date: Mon, 7 Mar 2016 06:49:19 +0000 Message-ID: References: <1457001868-15949-1-git-send-email-liang.z.li@intel.com> <20160303174615.GF2115@work-vm> <20160304081411.GD9100@rkaganb.sw.ru> <20160304102346.GB2479@rkaganb.sw.ru> <20160304163246-mutt-send-email-mst@redhat.com> <20160305214748-mutt-send-email-mst@redhat.com> In-Reply-To: <20160305214748-mutt-send-email-mst@redhat.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWJhOWQ5NjMtYjU5Ni00ZGRkLWJiYTctMTc5OGI0N2MzZTg1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkxnamFIOTVcL0R5c3NEUzNqdTFiOHptNUpkRGpkeWFcL1AzS296TzJMNmFMMD0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2274 Lines: 64 > > No. And it's exactly what I mean. The ballooned memory is still > > processed during live migration without skipping. The live migration code is > in migration/ram.c. > > So if guest acknowledged VIRTIO_BALLOON_F_MUST_TELL_HOST, we can > teach qemu to skip these pages. > Want to write a patch to do this? > Yes, we really can teach qemu to skip these pages and it's not hard. The problem is the poor performance, this PV solution is aimed to make it more efficient and reduce the performance impact on guest. > > > > > > > > > The only advantage of ' inflating the balloon before live > > > > > > migration' is simple, > > > > > nothing more. > > > > > > > > > > That's a big advantage. Another one is that it does something > > > > > useful in real- world scenarios. > > > > > > > > > > > > > I don't think the heave performance impaction is something useful > > > > in real > > > world scenarios. > > > > > > > > Liang > > > > > Roman. > > > > > > So fix the performance then. You will have to try harder if you want > > > to convince people that the performance is due to bad host/guest > > > interface, and so we have to change *that*. > > > > > > > Actually, the PV solution is irrelevant with the balloon mechanism, I > > just use it to transfer information between host and guest. > > I am not sure if I should implement a new virtio device, and I want to > > get the answer from the community. > > In this RFC patch, to make things simple, I choose to extend the > > virtio-balloon and use the extended interface to transfer the request and > free_page_bimap content. > > > > I am not intend to change the current virtio-balloon implementation. > > > > Liang > > And the answer would depend on the answer to my question above. > Does balloon need an interface passing page bitmaps around? Yes, I need a new interface. > Does this speed up any operations? No, a new interface will not speed up anything, but it is the easiest way to solve the compatibility issue. > OTOH what if you use the regular balloon interface with your patches? > The regular balloon interfaces have their specific function and I can't use them in my patches. If using these regular interface, I have to do a lot of changes to keep the compatibility. > > > > -- > > > MST