RE: [Xen-devel][PATCH] unshadow the page table page which areusedas data page

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Stephen C. Tweedie [mailto:sct@xxxxxxxxxx] 
>Sent: 2007年12月11日 1:07
>
>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.

All 0's means a valid mfn which falls out the unshadow check added here.

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

Yes.

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

Exactly.

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

Now I understand Keir's concern. The unshadow has effect on all 512/1024
entries within same page, and incorrect unshadow heuristics on one valid
pte entry hurts whole 4M/2M virtual range which is too overkill. Maybe we
can pattern the whole page like Keir said on present bit, which however is
not worthy since data page has 50% chance to have present bit set.

So such heuristics seems more meaningful only when present bit is set 
which is already done in existing shadow code.

Thanks,
Kevin

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