| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] RFC: Superpage/hugepage performance improvement
Hi,
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?
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?
And I guess it's up to the guest to make sure that no pagetables,
decriptor tables, &c end up in that memory.
> 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.)
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home