31 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH] turn off writ...
FromSent OnAttachments
Andrew Theurer25 Jul 2006 15:14.patch
Ian Pratt25 Jul 2006 15:41 
Nivedita Singhvi25 Jul 2006 15:43 
Andrew Theurer25 Jul 2006 16:19 
Andrew Theurer25 Jul 2006 19:24 
Jacob Gorm Hansen25 Jul 2006 22:31 
Gerd Hoffmann26 Jul 2006 01:17 
Keir Fraser26 Jul 2006 01:40 
Andrew Theurer26 Jul 2006 14:10 
Ian Pratt26 Jul 2006 14:38 
Joe Bonasera26 Jul 2006 16:38 
Andrew Theurer27 Jul 2006 07:43 
Keir Fraser27 Jul 2006 08:30 
Ian Pratt27 Jul 2006 10:31 
Keir Fraser28 Jul 2006 01:54 
Andrew Theurer28 Jul 2006 08:21 
Ian Pratt28 Jul 2006 08:51 
Keir Fraser28 Jul 2006 09:31 
Zachary Amsden28 Jul 2006 14:36.Other
Andi Kleen28 Jul 2006 16:05 
Zachary Amsden28 Jul 2006 16:10 
Mike Day28 Jul 2006 16:23 
Keir Fraser31 Jul 2006 02:13 
Zachary Amsden31 Jul 2006 02:31 
Keir Fraser31 Jul 2006 02:53 
Zachary Amsden31 Jul 2006 12:55 
Keir Fraser31 Jul 2006 15:07 
Zachary Amsden31 Jul 2006 15:39 
Keir Fraser02 Aug 2006 02:21 
Mike D. Day03 Aug 2006 13:41 
Andrew Theurer09 Aug 2006 14:14 
Subject:Re: [Xen-devel] [PATCH] turn off writable page tables
From:Keir Fraser (Keir@cl.cam.ac.uk)
Date:07/28/2006 09:31:07 AM
List:com.xensource.lists.xen-devel

On 28 Jul 2006, at 16:51, Ian Pratt wrote:

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?

I wouldn't mind seeing wrpt removed altogether, or at least emulation made the compile time default for the moment. There's bound to be some workload that bites us in the future which is why batching updates on the fork path mightn't be a bad thing if it can be done without too much gratuitous hacking of linux core code.

My only fear is that batched wrpt has some guest-visible effects. For example, the guest has to be able to cope with seeing page directory entries with the present bit cleared. Also, on SMP, it has to be able to cope with spurious page faults anywhere in its address space (e.g., faults on a unhooked page table which some other VCPU has rehooked by the time the Xen pagefault handler runs, hence the fault is bounced back to the guest even though there is no work to be done). If we turn off batched wrpt then guests will not be tested against it and we are likely to hit problems if we ever want to turn it back on again -- we'll find that some guests are not able to correctly handle the weird side effects.

On the other hand, perhaps we can find a neater more explicit alternative to batched wrpt in future.

-- Keir