|
xen-devel
Re: [Xen-devel] [PATCH] turn off writable page tables
Keir Fraser wrote:
On 27 Jul 2006, at 18:31, Ian Pratt wrote:
The obvious thing to do is emulate the first 4 updates to a particular
page, and only then switch to batched mode. Slows down the batched
path
a bit, but stops it firing in many cases where it is no help.
Why? There should be no overhead to just building batches on the stack
(or a per vcpu area) and flushing at the end of the page. Certainly if
we were to keep wrpt it would make sense to take a few emulations faults
first on a page before engaging wrpt, but for explicit batches we don't
need any smarts.
[Although the batching strategy would (currently) work for Linux, we do
have to bare in mind that some OSes (possibly NetBSD) won't rely on a
lock to protect updates to pagetables and will use individual atomic
ops.]
It wasn't clear to me there was a batching strategy that would
integrate nicely with Linux generic mm code and be useful to any other
OSes. We don't particularly want to accumulate OS-specific hacks
unless it's a significant win (which we have no evidence it would be
here).
I think there are only a couple of spots where batching is obvious (fork
parent being one). However, I don't think we'll see any significant
improvement, as we don't see any right now on typical workloads with
writable pages either. And I think that's the point I want to make -we
are not seeing an advantage for writable pages unless you have a
workload with a lot of dirty PTE's/page and it forks a lot, which
apparently does not seem to be that common (please, if anyone has one,
let me know, I would like to test it)
Now, if this were the only consequence, then I would not even bother
trying to remove writable page tables. However, the writable pages do
not scale with SMP guests, partly because of the single page available
(not counting the inactive page, since it's never used anymore), but
also because the tlb flush of all active cpus in that guest post page
detachment. Keeping writable page tables will probably also make
implementing a fine grain locking in the mm.c hypercall functions quite
difficult.
One other point: For those OSes which use cmpxchg on PTEs, I believe
keeping the emulate path will preserve the cmpxchg, so I don't think we
need wtpt for that. Alternatively, we could add a set_pte_cmpxchg call
if needed.
So, in summary, we know writable page tables are not broken, they just
don't help on typical workloads because the PTEs/page are so low.
However, they do hurt SMP guest performance. If we are not seeing a
benefit today, should we turn it off? Should we make it a compile time
option, with the default off?
Thanks,
-Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home