[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160309142851.GA9715@rkaganb.sw.ru>
Date: Wed, 9 Mar 2016 17:28:54 +0300
From: Roman Kagan <rkagan@...tuozzo.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: "Li, Liang Z" <liang.z.li@...el.com>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
"ehabkost@...hat.com" <ehabkost@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"quintela@...hat.com" <quintela@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"amit.shah@...hat.com" <amit.shah@...hat.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"rth@...ddle.net" <rth@...ddle.net>, <riel@...hat.com>
Subject: Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration
optimization
On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote:
> On Mon, Mar 07, 2016 at 06:49:19AM +0000, Li, Liang Z wrote:
> > > > 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
>
> Balloon is always PV. And do not call patches solutions please.
>
> > is aimed to make it more
> > efficient and reduce the performance impact on guest.
>
> We need to get a bit beyond this. You are making multiple
> changes, it seems to make sense to split it all up, and analyse each
> change separately.
Couldn't agree more.
There are three stages in this optimization:
1) choosing which pages to skip
2) communicating them from guest to host
3) skip transferring uninteresting pages to the remote side on migration
For (3) there seems to be a low-hanging fruit to amend
migration/ram.c:iz_zero_range() to consult /proc/self/pagemap. This
would work for guest RAM that hasn't been touched yet or which has been
ballooned out.
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.
As for (2), we do seem to have a problem with the existing balloon:
according to your measurements it's very slow; besides, I guess it plays
badly with transparent huge pages (as both the guest and the host work
with one 4k page at a time). This is a problem for other use cases of
balloon (e.g. as a facility for resource management); tackling that
appears a more natural application for optimization efforts.
Thanks,
Roman.
Powered by blists - more mailing lists