[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160310102129.GB14065@rkaganb.sw.ru>
Date: Thu, 10 Mar 2016 13:21:30 +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 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.
Powered by blists - more mailing lists