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

RE: [Xen-devel] [PATCH] turn off writable page tables



xen-devel-request@xxxxxxxxxxxxxxxxxxx wrote:


Message: 1
Date: Wed, 26 Jul 2006 22:38:32 +0100
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] turn off writable page tables
To: "Andrew Theurer" <habanero@xxxxxxxxxx>,     "Keir Fraser"
        <Keir.Fraser@xxxxxxxxxxxx>
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Gerd Hoffmann
        <kraxel@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID:
        <A95E2296287EAD4EB592B5DEEFCE0E9D572247@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain;       charset="us-ascii"

And it does make a difference in this case.  I now have a test program
which dirties a number of virtually contiguous pages then forks (it
also
resets xen perf counters before fork and collects perf counters right
after fork), then records the elapsed time for the fork.  The
difference
is quite amazing in this case.  For both writable and emulate, I ran
with a range of dirty pages, from 1280 to 128000.  The elapsed times
for
fork a quite linear from small number to large number of dirty pages.
Below are the min and max:

         1280 pages    128000 pages
wtpt:     813 usec      37552 usec
emulate: 3279 usec     283879 usec

Good, at least that suggests that the code works for the usage it was
intended for.
So, in a -perfect-world- this works great.  Problem is most workloads
don't appear to have a vast percentage of entries that need to be
updated.   I'll go ahead and  expand this test to find out what the
threshold is to break even.  I'll also see if we can implement a
batched
call in fork to update the parent -I hope this will show just as good
performance even when most entries need modification and even better
performance over wtpt with a low number of entries modified.

With license to make more invasive changes to core Linux mm it certainly
should be possible to optimize this specific case with a batched update
fairly easily. You could even go further an implement a 'make all PTEs
in pagetable RO' hypercall, possibly including a copy to the child. This
could potentially work better than current 'late pin', at least the
validation would be incremental rather than in one big hit at the end.
Ian

OpenSolaris could easily use the "make all PTEs in pagetable RO" hypercall.
But we don't copy in bulk to the child, so if you go down that path
please make the copy to child part optional.

Joe

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


 


Rackspace

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