From: Ian Campbell <ian.campbell@citrix.com>
To: Gareth Stockwell <Gareth.Stockwell@arm.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-users] Grant reference batch transmission
Date: Wed, 11 Mar 2015 10:54:25 +0000 [thread overview]
Message-ID: <1426071265.21353.172.camel@citrix.com> (raw)
In-Reply-To: <DA845EDCE27355428C520DC5B8DC05CE47E7A933BC@GEORGE.Emea.Arm.com>
On Wed, 2015-03-11 at 10:40 +0000, Gareth Stockwell wrote:
> On Wed, Mar 11, 2015 at 10:24:48, Ian Campbell wrote:
> > > I think this gives us two options for grant reference batch transmission:
> > >
> > > 1. Send the grant references via the ring buffer.
> > > This doesn't require any additional allocations, but means that if
> > > the number of grant references in the batch is greater than
> > > O(sizeof(ringbuffer) / sizeof(grant_ref_t)), cycling through the
> > > ring will be required.
> >
> > Correct. In fact it's a bit worse because the ring pointers steal a
> > bit of space out of the shared page. You might also find that in
> > practice you want an id in the request which is echoed back in the response e.g.
> > to handle out of order completion (depends on your use case though),
> > which would increase sizeof(grant_ref_t) (which is really sizeof(my_req_t)).
> >
> > What sorts of batch sizes are you expecting to see in your use case?
>
> We need to share hundreds of MB, so (assuming a 4kB guest page size)
> the batch size can be thousands of grant references.
FWIW, the granularity of a gref is 4kB irrespective of the guest's page
size (so e.g. a 64Kb page would need 16 grefs to cover it), so your
calculation is correct everywhere.
We have been considering allow "superpage" grants of higher order
mappings, but no work has been done on that yet. You such a feature be
useful or are your hundreds of MB scattered?
I suppose the 100s of MB is changing reasonable often (e.g. not just a
start of day setup thing) otherwise the performance/efficiency of gref
communications wouldn't be such an issue.
Ian.
next prev parent reply other threads:[~2015-03-11 10:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DA845EDCE27355428C520DC5B8DC05CE47E7A93173@GEORGE.Emea.Arm.com>
2015-03-10 16:22 ` [Xen-users] Grant reference batch transmission Ian Campbell
2015-03-11 10:12 ` Gareth Stockwell
2015-03-11 10:24 ` Ian Campbell
2015-03-11 10:40 ` Gareth Stockwell
2015-03-11 10:54 ` Ian Campbell [this message]
2015-03-11 13:30 ` Gareth Stockwell
2015-03-12 10:43 ` Ian Campbell
2015-03-11 10:43 ` Wei Liu
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=1426071265.21353.172.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Gareth.Stockwell@arm.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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.