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/
Home Products Support Community News


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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] turn off writable page tables
From: Andrew Theurer <habanero@xxxxxxxxxx>
Date: Fri, 28 Jul 2006 10:21:41 -0500
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Jul 2006 08:22:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <5caa8fb011765c921f27ce8a131316b0@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D57226B@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <5caa8fb011765c921f27ce8a131316b0@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20060516)
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
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

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?



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>