WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel][PATCH] unshadow the page table page which areused as dat

Hi,

On Mon, 2007-12-10 at 16:40 +0800, Tian, Kevin wrote:

> Will OS use those unused ptes in performance critical path?

There's one extremely common case for Linux --- the special "empty" pte,
"pte_none" (usually all-zeros), which is used in live memory areas to
represent unfaulted fault-on-demand memory.  munmap will write that
value all over live page tables, and in some workloads that's a
performance-sensitive operation.


Other than that, fork and exit are the obvious cases which actively walk
page tables containing mixed present and swap ptes.  

For fork, any !PAGE_PRESENT swap ptes will be read to bump the refcount
on the swap page.  Any COW ptes in the same page table will be copied
and set read-only at the same time.

But that may not be too bad --- the swap entries in the existing page
table will only be getting read, not written, so they won't trigger the
unsharing code.  The COW ptes will be written, but those are all valid
ptes so again they won't trigger any undesirable unsharing.  

And in the new page table, we'll be mixing writes of the valid ptes and
the swap entries... but the page table won't be "live" by then so I
don't think we'll have those ptes shadowed at all at that point.


I _think_ we're OK for exit, too --- that again only reads, rather than
writes, the swap ptes.


So as long as we're not triggering an unshare when pte_none is written,
I don't think this will hit Linux's hot paths too much.  It will
definitely hurt the "soft" swapout case where the page is getting
unhooked from one mm but is still in use elsewhere, but if we're on that
path then we're already straying from peak performance.


Cheers,
 Stephen



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