From: "Wang, Wei W" <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Amit Shah <amit.shah@redhat.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
Liang Li <liliang324@gmail.com>
Subject: RE: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
Date: Mon, 13 Mar 2017 12:41:39 +0000 [thread overview]
Message-ID: <286AC319A985734F985F78AFA26841F73919FFDB@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20170312055658-mutt-send-email-mst@kernel.org>
On Sunday, March 12, 2017 12:04 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote:
> > On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > > I'm thinking what if the guest needs to transfer these much
> > > > physically continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > > > Is it going to use Six 64-bit chunks? Would it be simpler if we
> > > > just use the 128-bit chunk format (we can drop the previous normal
> > > > 64-bit format)?
> > >
> > > Is that a likely thing for the guest to need to do though? Freeing
> > > a 1GB page is much more liikely, IMO.
> >
> > Yes, I think it's very possible. The host can ask for any number of pages (e.g.
> 1.5GB) that the guest can afford. Also, the ballooned 1.5G memory is not
> guaranteed to be continuous in any pattern like 1GB+512MB. That's why we
> need to use a bitmap to draw the whole picture first, and then seek for
> continuous bits to chunk.
> >
> > Best,
> > Wei
>
> While I like the clever format that Matthew came up with, I'm also inclined to
> say let's keep things simple.
> the simplest thing seems to be to use the ext format all the time.
> Except let's reserve the low 12 bits in both address and size, since they are
> already 0, we might be able to use them for flags down the road.
Thanks for reminding us about the hugepage story. I'll use the ext format in the implementation if no further objections from others.
Best,
Wei
WARNING: multiple messages have this Message-ID (diff)
From: "Wang, Wei W" <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Amit Shah <amit.shah@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Liang Li <liliang324@gmail.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: RE: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
Date: Mon, 13 Mar 2017 12:41:39 +0000 [thread overview]
Message-ID: <286AC319A985734F985F78AFA26841F73919FFDB@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20170312055658-mutt-send-email-mst@kernel.org>
On Sunday, March 12, 2017 12:04 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote:
> > On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > > I'm thinking what if the guest needs to transfer these much
> > > > physically continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > > > Is it going to use Six 64-bit chunks? Would it be simpler if we
> > > > just use the 128-bit chunk format (we can drop the previous normal
> > > > 64-bit format)?
> > >
> > > Is that a likely thing for the guest to need to do though? Freeing
> > > a 1GB page is much more liikely, IMO.
> >
> > Yes, I think it's very possible. The host can ask for any number of pages (e.g.
> 1.5GB) that the guest can afford. Also, the ballooned 1.5G memory is not
> guaranteed to be continuous in any pattern like 1GB+512MB. That's why we
> need to use a bitmap to draw the whole picture first, and then seek for
> continuous bits to chunk.
> >
> > Best,
> > Wei
>
> While I like the clever format that Matthew came up with, I'm also inclined to
> say let's keep things simple.
> the simplest thing seems to be to use the ext format all the time.
> Except let's reserve the low 12 bits in both address and size, since they are
> already 0, we might be able to use them for flags down the road.
Thanks for reminding us about the hugepage story. I'll use the ext format in the implementation if no further objections from others.
Best,
Wei
WARNING: multiple messages have this Message-ID (diff)
From: "Wang, Wei W" <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Amit Shah <amit.shah@redhat.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Hildenbrand <david@redhat.com>,
Liang Li <liliang324@gmail.com>
Subject: RE: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
Date: Mon, 13 Mar 2017 12:41:39 +0000 [thread overview]
Message-ID: <286AC319A985734F985F78AFA26841F73919FFDB@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20170312055658-mutt-send-email-mst@kernel.org>
On Sunday, March 12, 2017 12:04 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote:
> > On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > > I'm thinking what if the guest needs to transfer these much
> > > > physically continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > > > Is it going to use Six 64-bit chunks? Would it be simpler if we
> > > > just use the 128-bit chunk format (we can drop the previous normal
> > > > 64-bit format)?
> > >
> > > Is that a likely thing for the guest to need to do though? Freeing
> > > a 1GB page is much more liikely, IMO.
> >
> > Yes, I think it's very possible. The host can ask for any number of pages (e.g.
> 1.5GB) that the guest can afford. Also, the ballooned 1.5G memory is not
> guaranteed to be continuous in any pattern like 1GB+512MB. That's why we
> need to use a bitmap to draw the whole picture first, and then seek for
> continuous bits to chunk.
> >
> > Best,
> > Wei
>
> While I like the clever format that Matthew came up with, I'm also inclined to
> say let's keep things simple.
> the simplest thing seems to be to use the ext format all the time.
> Except let's reserve the low 12 bits in both address and size, since they are
> already 0, we might be able to use them for flags down the road.
Thanks for reminding us about the hugepage story. I'll use the ext format in the implementation if no further objections from others.
Best,
Wei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Wang, Wei W" <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Amit Shah <amit.shah@redhat.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Hildenbrand <david@redhat.com>,
Liang Li <liliang324@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
Date: Mon, 13 Mar 2017 12:41:39 +0000 [thread overview]
Message-ID: <286AC319A985734F985F78AFA26841F73919FFDB@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20170312055658-mutt-send-email-mst@kernel.org>
On Sunday, March 12, 2017 12:04 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote:
> > On 03/11/2017 10:10 PM, Matthew Wilcox wrote:
> > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote:
> > > > I'm thinking what if the guest needs to transfer these much
> > > > physically continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB.
> > > > Is it going to use Six 64-bit chunks? Would it be simpler if we
> > > > just use the 128-bit chunk format (we can drop the previous normal
> > > > 64-bit format)?
> > >
> > > Is that a likely thing for the guest to need to do though? Freeing
> > > a 1GB page is much more liikely, IMO.
> >
> > Yes, I think it's very possible. The host can ask for any number of pages (e.g.
> 1.5GB) that the guest can afford. Also, the ballooned 1.5G memory is not
> guaranteed to be continuous in any pattern like 1GB+512MB. That's why we
> need to use a bitmap to draw the whole picture first, and then seek for
> continuous bits to chunk.
> >
> > Best,
> > Wei
>
> While I like the clever format that Matthew came up with, I'm also inclined to
> say let's keep things simple.
> the simplest thing seems to be to use the ext format all the time.
> Except let's reserve the low 12 bits in both address and size, since they are
> already 0, we might be able to use them for flags down the road.
Thanks for reminding us about the hugepage story. I'll use the ext format in the implementation if no further objections from others.
Best,
Wei
next prev parent reply other threads:[~2017-03-13 12:41 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 5:40 [PATCH v7 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [PATCH v7 kernel 1/5] virtio-balloon: rework deflate to add page to a list Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [PATCH v7 kernel 2/5] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-08 4:01 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-09 7:12 ` Wei Wang
2017-03-09 7:12 ` [Qemu-devel] " Wei Wang
2017-03-09 7:12 ` Wei Wang
2017-03-09 7:12 ` Wei Wang
2017-03-09 7:12 ` Wei Wang
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-08 4:01 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-08 4:01 ` Michael S. Tsirkin
2017-03-10 10:02 ` [virtio-dev] " Wei Wang
2017-03-10 10:02 ` [Qemu-devel] " Wei Wang
2017-03-10 10:02 ` Wei Wang
2017-03-10 10:02 ` Wei Wang
2017-03-10 13:26 ` [virtio-dev] " David Hildenbrand
2017-03-10 13:26 ` [Qemu-devel] " David Hildenbrand
2017-03-10 13:26 ` David Hildenbrand
2017-03-10 13:26 ` David Hildenbrand
2017-03-10 15:37 ` Michael S. Tsirkin
2017-03-10 15:37 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-10 15:37 ` Michael S. Tsirkin
2017-03-10 15:37 ` Michael S. Tsirkin
2017-03-10 10:02 ` Wei Wang
2017-03-09 14:14 ` Matthew Wilcox
2017-03-09 14:14 ` [Qemu-devel] " Matthew Wilcox
2017-03-09 14:14 ` Matthew Wilcox
2017-03-10 11:37 ` Wei Wang
2017-03-10 11:37 ` Wei Wang
2017-03-10 11:37 ` [Qemu-devel] " Wei Wang
2017-03-10 11:37 ` Wei Wang
2017-03-10 15:58 ` Michael S. Tsirkin
2017-03-10 15:58 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-10 15:58 ` Michael S. Tsirkin
2017-03-10 17:11 ` Matthew Wilcox
2017-03-10 17:11 ` [Qemu-devel] " Matthew Wilcox
2017-03-10 17:11 ` Matthew Wilcox
2017-03-10 19:10 ` Michael S. Tsirkin
2017-03-10 19:10 ` Michael S. Tsirkin
2017-03-10 19:10 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-10 19:10 ` Michael S. Tsirkin
2017-03-10 21:18 ` Matthew Wilcox
2017-03-10 21:18 ` [Qemu-devel] " Matthew Wilcox
2017-03-10 21:18 ` Matthew Wilcox
2017-03-10 21:18 ` Matthew Wilcox
2017-03-10 19:35 ` Michael S. Tsirkin
2017-03-10 19:35 ` Michael S. Tsirkin
2017-03-10 19:35 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-10 19:35 ` Michael S. Tsirkin
2017-03-10 21:25 ` Matthew Wilcox
2017-03-10 21:25 ` Matthew Wilcox
2017-03-10 21:25 ` [Qemu-devel] " Matthew Wilcox
2017-03-10 21:25 ` Matthew Wilcox
2017-03-12 0:05 ` Michael S. Tsirkin
2017-03-12 0:05 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-12 0:05 ` Michael S. Tsirkin
2017-03-12 0:05 ` Michael S. Tsirkin
2017-03-11 11:59 ` Wei Wang
2017-03-11 11:59 ` [Qemu-devel] " Wei Wang
2017-03-11 11:59 ` Wei Wang
2017-03-11 14:09 ` Matthew Wilcox
2017-03-11 14:09 ` Matthew Wilcox
2017-03-11 14:09 ` [Qemu-devel] " Matthew Wilcox
2017-03-11 14:09 ` Matthew Wilcox
2017-03-12 1:59 ` Wang, Wei W
2017-03-12 1:59 ` Wang, Wei W
2017-03-12 1:59 ` [Qemu-devel] " Wang, Wei W
2017-03-12 1:59 ` Wang, Wei W
2017-03-12 1:59 ` Wang, Wei W
2017-03-12 4:04 ` Michael S. Tsirkin
2017-03-12 4:04 ` Michael S. Tsirkin
2017-03-12 4:04 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-12 4:04 ` Michael S. Tsirkin
2017-03-12 4:04 ` Michael S. Tsirkin
2017-03-13 12:41 ` Wang, Wei W [this message]
2017-03-13 12:41 ` [Qemu-devel] " Wang, Wei W
2017-03-13 12:41 ` Wang, Wei W
2017-03-13 12:41 ` Wang, Wei W
2017-03-12 0:07 ` Michael S. Tsirkin
2017-03-12 0:07 ` Michael S. Tsirkin
2017-03-12 0:07 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-12 0:07 ` Michael S. Tsirkin
2017-03-11 11:59 ` Wei Wang
2017-03-10 17:11 ` Matthew Wilcox
2017-03-10 15:58 ` Michael S. Tsirkin
2017-03-09 14:14 ` Matthew Wilcox
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [PATCH v7 kernel 4/5] virtio-balloon: define flags and head for host request vq Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-08 4:02 ` Michael S. Tsirkin
2017-03-08 4:02 ` [Qemu-devel] " Michael S. Tsirkin
2017-03-08 4:02 ` Michael S. Tsirkin
2017-03-08 4:02 ` Michael S. Tsirkin
2017-03-03 5:40 ` [PATCH v7 kernel 5/5] This patch contains two parts: Wei Wang
2017-03-03 5:40 ` [Qemu-devel] " Wei Wang
2017-03-03 5:40 ` Wei Wang
2017-03-06 13:23 ` David Hildenbrand
2017-03-06 13:23 ` [Qemu-devel] " David Hildenbrand
2017-03-06 13:23 ` David Hildenbrand
2017-03-09 7:04 ` Wei Wang
2017-03-09 7:04 ` Wei Wang
2017-03-09 7:04 ` [Qemu-devel] " Wei Wang
2017-03-09 7:04 ` Wei Wang
2017-03-06 13:23 ` David Hildenbrand
2017-03-03 5:40 ` Wei Wang
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=286AC319A985734F985F78AFA26841F73919FFDB@shsmsx102.ccr.corp.intel.com \
--to=wei.w.wang@intel.com \
--cc=aarcange@redhat.com \
--cc=amit.shah@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=liliang324@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.