Re: RFC: Superpage/hugepage performance improvement

[Dave McCracken <dcm@mccr.org>]

On Tuesday 06 April 2010, Tim Deegan wrote:
> At 18:52 +0100 on 05 Apr (1270493549), Dave McCracken wrote:
> > In our testing we found that the superpage/hugepage mapping code is
> > seriously bogged down by the need to maintain the reference count on
> > each of the underlying pages every time a hugepage is mapped.  I came
> > up with a fix where a guest can call into the hypervisor to mark a set
> > of pages as a superpage, thus locking that set of pages to be
> > read/write data pages until the corresponding unmark is call is made.
> 
> Hmm.  That sounds OK, as long as we haven't ended up with a way for a
> guest to manipulate Xen's typecounts (either by double-freeing and
> underflowing them or by leaving typecounts non-zero on domain
> destruction).  How does it work internally?  Does it take a typecount
> on each page and keep a separate flag/refcount per superpage so the
> guest can't double-free?

I do set a flag on the leading page of the superpage, and increment the 
writable typecount on each of the underlying pages.  Then when the page is 
subsequently mapped I only increment the typecount of the leading page.
 
Setting and unsetting the superpage flag can not be nested.  Attempts to double 
free will be rejected.

> How is it synchronized with PTE changes?  e.g. how do we make sure that
> all the superpage PTEs that map an area of memory are are gone before
> the guest can unmark the memory?

Hmm... I don't have a bulletproof solution to that one yet.  It's complicated 
by the fact that on Linux, at least, all free pages may have a writable 
typecount of either 0 or 1, depending on whether they're highmem pages.
 
> And I guess it's up to the guest to make sure that no pagetables,
> decriptor tables, &c end up in that memory.

Yes, that's correct.  This mechanism is fundamentally incompatible with using 
the pages for anything other than writable data.  Their attempts should fail.

> > To make this work I added two mmuext ops, one to mark a superpage and
> > one to unmark it.  This change makes a huge performance difference in
> > the hugepage mapping (on the order of 50 times faster).
> 
> Plus, presumably, some noticeable difference on a macro benchmark. (I
> expect that's the case but I've been wrong before.)

The original reason I came up with this mechanism was that one of our real 
applications would not run due to the poor performance.  They have something 
like a 64G region fully populated with hugepages.  This region has to be 
mapped in the child on every fork.  It was so slow their operations were 
timing out.

Dave McCracken
Oracle Corp.