[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Any work on sharing of large multi-page segments?

  • To: xen-devel@xxxxxxxxxxxxx
  • From: Andrew Warkentin <andreww591@xxxxxxxxx>
  • Date: Mon, 16 Mar 2015 18:46:42 -0600
  • Delivery-date: Tue, 17 Mar 2015 00:47:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 3/16/15, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> So where do you expect the major performance / scalability
> improvement to be gained? Internally to Xen, each page will need
> to be tracked separately anyway, as what appears physically
> contiguous in the granting guest may (and likely will) not be
> contiguous in machine memory (i.e. from Xen's perspective).
> Furthermore the public interface is currently written such that
> grant lengths must be less than 64k. I.e. already at the very
> simple first steps you'd be faced with implementing bigger length
> counterparts of (almost) all existing interfaces.

Since I'm looking to grant OpenGL buffers that can be many megabytes
in size, I would think there would be a fair bit of overhead if the
backend domain had to make a hypercall to map every single page of a
buffer. I guess what I could do would be to add a hypercall that maps
a contiguous group of grant entries (contiguous in the grant table,
not necessarily contiguous in memory).

> No, grants are explicitly not intended to be used for code (or data)
> sharing, only for data exchange: They're being mapped with the
> executable flag clear. For code and (read-only) data sharing you'll
> want to use the page sharing facility instead.

I was thinking more of explicit sharing of code rather than automatic
deduplication (at least I'm assuming you're talking about the
deduplication support that was added a while back). I would imagine
there would be some overhead associated with deduplication whereas
explicit sharing would incur relatively little overhead. For a desktop
that's running relatively few VMs that are often going to be
dissimilar, the overhead of deduplication might not be worth it. Also,
I was wanting to make my disaggregated Xen system entirely
memory-resident except for the storage domain (it should be
lightweight enough), and it would make more sense to create a service
domain by mapping everything into its address space when building it,
rather than copying it from dom0 and waiting for the deduplication to
kick in.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.