From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Li, Liang Z" <liang.z.li@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"amit.shah@redhat.com" <amit.shah@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH RFC kernel] balloon: speed up inflating/deflating process
Date: Wed, 25 May 2016 11:57:23 +0300 [thread overview]
Message-ID: <20160525115419-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E041A6C67@shsmsx102.ccr.corp.intel.com>
On Wed, May 25, 2016 at 08:48:17AM +0000, Li, Liang Z wrote:
> > > > Suggestion to address all above comments:
> > > > 1. allocate a bunch of pages and link them up,
> > > > calculating the min and the max pfn.
> > > > if max-min exceeds the allocated bitmap size,
> > > > tell host.
> > >
> > > I am not sure if it works well in some cases, e.g. The allocated pages
> > > are across a wide range and the max-min > limit is very frequently to be
> > true.
> > > Then, there will be many times of virtio transmission and it's bad for
> > > performance improvement. Right?
> >
> > It's a tradeoff for sure. Measure it, see what the overhead is.
> >
>
> Hi MST,
>
> I have measured the performance when using a 32K page bitmap,
Just to make sure. Do you mean a 32Kbyte bitmap?
Covering 1Gbyte of memory?
> and inflate the balloon to 3GB
> of an idle guest with 4GB RAM.
Should take 3 requests then, right?
> Now:
> total inflating time: 338ms
> the count of virtio data transmission: 373
Why was this so high? I would expect 3 transmissions.
> the call count of madvise: 865
>
> before:
> total inflating time: 175ms
> the count of virtio data transmission: 1
> the call count of madvise: 42
>
> Maybe the result will be worse if the guest is not idle, or the guest has more RAM.
> Do you want more data?
>
> Is it worth to do that?
>
> Liang
Either my math is wrong or there's an implementation bug.
> > >
> > > > 2. limit allocated bitmap size to something reasonable.
> > > > How about 32Kbytes? This is 256kilo bit in the map, which comes
> > > > out to 1Giga bytes of memory in the balloon.
> > >
> > > So, even the VM has 1TB of RAM, the page bitmap will take 32MB of
> > memory.
> > > Maybe it's better to use a big page bitmap the save the pages
> > > allocated by balloon, and split the big page bitmap to 32K bytes unit, then
> > transfer one unit at a time.
> >
> > How is this different from what I said?
> >
> > >
> > > Should we use a page bitmap to replace 'vb->pages' ?
> > >
> > > How about rolling back to use PFNs if the count of requested pages is a
> > small number?
> > >
> > > Liang
> >
> > That's why we have start pfn. you can use that to pass even a single page
> > without a lot of overhead.
> >
> > > > > --
> > > > > 1.9.1
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > > > the body of a message to majordomo@vger.kernel.org More majordomo
> > > > info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-05-25 8:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 9:59 [Qemu-devel] [PATCH RFC kernel] balloon: speed up inflating/deflating process Liang Li
2016-05-20 10:32 ` Cornelia Huck
2016-05-24 7:48 ` Li, Liang Z
2016-05-20 11:19 ` Paolo Bonzini
2016-05-24 7:51 ` Li, Liang Z
2016-05-20 12:00 ` Michael S. Tsirkin
2016-05-24 9:51 ` Li, Liang Z
2016-05-24 9:55 ` Li, Liang Z
2016-05-24 10:08 ` Michael S. Tsirkin
2016-05-24 10:38 ` Li, Liang Z
2016-05-24 11:11 ` Michael S. Tsirkin
2016-05-24 14:36 ` Li, Liang Z
2016-05-24 15:12 ` Michael S. Tsirkin
2016-05-25 0:52 ` Li, Liang Z
2016-05-25 1:00 ` Li, Liang Z
2016-05-25 8:35 ` Michael S. Tsirkin
2016-05-25 8:48 ` Li, Liang Z
2016-05-25 8:57 ` Michael S. Tsirkin [this message]
2016-05-25 9:28 ` Li, Liang Z
2016-05-25 9:40 ` Michael S. Tsirkin
2016-05-25 10:10 ` Li, Liang Z
2016-05-25 10:37 ` Michael S. Tsirkin
2016-05-25 14:29 ` Li, Liang Z
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160525115419-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=amit.shah@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=liang.z.li@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).