[Xen-devel] Re: [PATCH] Add hypercall to mark superpages to improve performance

[Dave McCracken <dcm@xxxxxxxx>]

On Friday 30 April 2010, Keir Fraser wrote:
> I'd actually have two refcounts in superpage struct: one for read-only
> mappings and one for read-write mappings. The latter would be updated as
> above except for the use of {get,put}_page_and_type() instead of
> {get,put}_page().
> 
> The other thing to note is that this approach is cheap when updating
> superpage refcounts between non-zero values. If regularly
> constructing/destroying the only superpage mapping of a page, then
> obviously you are going to be continually taking the slow path. In that
> case, pinning a superpage with new hypercalls as you suggested may have to
> be done. It kind of depends on how your workloads interact with the
> reference-counting. In any case, you could implement the basic version as
> described here, and add hypercalls as a second stage if they turn out to be
> needed.

I have an alternative idea...

Make the superpage struct contain a single typecount field.  The two possible 
values fortype would be "superpage" and "conflicts with superpage".  The 
semantics of this typecount field would be the same as page_info... it can only 
change type when the count is zero.

The "superpage" type counts the times this superpage is mapped.

The "conflicts with superpage" type is used whenever any page in the superpage 
is set to a type that would conflict with a superpage mapping, basically any 
type other than readonly or read/write.  The count would be the sum of the 
mappings of the pages in the superpage with a conflicting type.

Permission checking would be very simple.  If get_superpage_and_type() returns 
a type mismatch error then the mapping will fail, in exactly the same fashion 
as get_page_and_type().

This model would completely eliminate the need to walk the pages in a 
superpage at mapping time, at the cost of one 
get_superpage_and_type()/put_superpage_and_type(). on each page table page.

One outstanding issue I see is how to handle readonly mappings.  If we follow 
the model of regular page typecount, readonly mappings of superpages would not 
conflict with the "conflicts with superpage" type.  This means a subsequent 
attempt to change it to a read/write mapping could fail, just like with a 
regular page.  Or we could count all mappings of superpages as if they were 
read/write.

What are your thoughts?  It seems fairly simple and elegant to me, and at this 
point I don't see any big holes in it.

Dave McCracken
Oracle Corp.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel