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

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

  • To: Dave McCracken <dcm@xxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Sun, 2 May 2010 16:54:56 -0700
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen Developers List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 02 May 2010 16:56:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcrqP4Trj5SNGNzgTO6NvnO23nvajwAE1i3/
  • Thread-topic: [PATCH] Add hypercall to mark superpages to improve performance

On 02/05/2010 14:34, "Dave McCracken" <dcm@xxxxxxxx> wrote:

> 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.

I'd keep an extra refcount in superpage_info to track read-only mappings (or
all superpage mappings, as page->count_info does for 4kB mappings). It's
trivial extra space and avoids having unexpected extra restrictions on
read-only superpage mappings.

> 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.

It does mean that creating/destroying pagetable pages causes an extra locked
read-modify-write cycle on a non-local cacheline (superpage_info refcount).
Would this be significant? Not sure. I guess we'd only be doing it for
guests with the superpage capability configured, and we could do some
performance comparisons with the capability enabled/disabled. I think
overall I quite like your suggestion.

 -- Keir

Xen-devel mailing list



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