Re: Any work on sharing of large multi-page segments?

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-03-17 at 17:45 -0600, Andrew Warkentin wrote:
> On 3/17/15, Jan Beulich <JBeulich@suse.com> wrote:
> > And how would that be significantly different from the batching
> > that's already built into the grant table hypercall?
> >
> I guess it does do more or less what I want already. I was looking
> more at the inner mapping/unmapping functions, rather than the
> wrappers around them that implement the actual hypercalls.
> 
> What would be a useful addition would be support for granting 2M
> pages. That would eliminate any problem with running out of grant
> table slots.

It's related but not quite the same but on ARM we are probably
eventually going to want to look into support for 64K grant mappings at
some point.

On ARM there are several options for the basic leaf page (called
"granules") size, 4K, 16K and 64K and it seems that at least some
OS/distro vendors are going to ship their kernels with 64K pages by
default, so we need to be able to support such guests.

Short term we can deal with this in the front/backend by using multiple
grants per guest page (i.e. 16 grants per 64K page) but that is quite
wasteful of ring space. Longer term I think it would be worth
investigating adding grant table extensions to allow for >4K granule
sizes.

>From there it's not too much of a stretch to imagine supporting
superpages of whichever granule size (i.e. 2M in the 4K case might be
sane, 32M in the 64K case perhaps less useful). 

Even without that Linux will use compound pages e.g. for network frags
(up to order 3 == 32k, I think), so supporting higher order grants might
even be useful there even on x86.

Internally we'd still need to deal with all this in Xen as 4K mappings
in the second stage pages, but that's doable I think.

It's not clear when this would float to the top of priority list for Xen
on ARM though, so I wouldn't wait for us ;-)

Ian.