[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <286AC319A985734F985F78AFA26841F7391FFBB0@shsmsx102.ccr.corp.intel.com>
Date: Sun, 7 May 2017 04:19:28 +0000
From: "Wang, Wei W" <wei.w.wang@...el.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: "virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"david@...hat.com" <david@...hat.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"cornelia.huck@...ibm.com" <cornelia.huck@...ibm.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mgorman@...hsingularity.net" <mgorman@...hsingularity.net>,
"aarcange@...hat.com" <aarcange@...hat.com>,
"amit.shah@...hat.com" <amit.shah@...hat.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"liliang.opensource@...il.com" <liliang.opensource@...il.com>
Subject: RE: [virtio-dev] Re: [PATCH v9 2/5] virtio-balloon:
VIRTIO_BALLOON_F_BALLOON_CHUNKS
On 05/06/2017 06:26 AM, Michael S. Tsirkin wrote:
> On Thu, Apr 27, 2017 at 02:31:49PM +0800, Wei Wang wrote:
> > On 04/27/2017 07:20 AM, Michael S. Tsirkin wrote:
> > > On Wed, Apr 26, 2017 at 11:03:34AM +0000, Wang, Wei W wrote:
> > > > Hi Michael, could you please give some feedback?
> > > I'm sorry, I'm not sure feedback on what you are requesting.
> > Oh, just some trivial things (e.g. use a field in the header,
> > hdr->chunks to indicate the number of chunks in the payload) that
> > wasn't confirmed.
> >
> > I will prepare the new version with fixing the agreed issues, and we
> > can continue to discuss those parts if you still find them improper.
> >
> >
> > >
> > > The interface looks reasonable now, even though there's a way to
> > > make it even simpler if we can limit chunk size to 2G (in fact 4G -
> > > 1). Do you think we can live with this limitation?
> > Yes, I think we can. So, is it good to change to use the previous
> > 64-bit chunk format (52-bit base + 12-bit size)?
>
> This isn't what I meant. virtio ring has descriptors with a 64 bit address and 32 bit
> size.
>
> If size < 4g is not a significant limitation, why not just use that to pass
> address/size in a standard s/g list, possibly using INDIRECT?
OK, I see your point, thanks. Post the two options here for an analysis:
Option1 (what we have now):
struct virtio_balloon_page_chunk {
__le64 chunk_num;
struct virtio_balloon_page_chunk_entry entry[];
};
Option2:
struct virtio_balloon_page_chunk {
__le64 chunk_num;
struct scatterlist entry[];
};
I don't have an issue to change it to Option2, but I would prefer Option1,
because I think there is no be obvious difference between the two options,
while Option1 appears to have little advantages here:
1) "struct virtio_balloon_page_chunk_entry" has smaller size than
"struct scatterlist", so the same size of allocated page chunk buffer
can hold more entry[] using Option1;
2) INDIRECT needs on demand kmalloc();
3) no 4G size limit;
What do you think?
Best,
Wei
Powered by blists - more mailing lists