similar to: [PATCH 0/4] i386 - pte update optimizations

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

In situations where page table updates need only be made locally, and there is no cross-processor A/D bit races involved, we need not use the heavyweight xchg instruction to atomically fetch and clear page table entries. Instead, we can just read and clear them directly. This introduces a neat optimization for non-SMP kernels; drop the atomic xchg operations from page table updates. Thanks to

In situations where page table updates need only be made locally, and there is no cross-processor A/D bit races involved, we need not use the heavyweight xchg instruction to atomically fetch and clear page table entries. Instead, we can just read and clear them directly. This introduces a neat optimization for non-SMP kernels; drop the atomic xchg operations from page table updates. Thanks to

Change pte_clear_full to a more appropriately named pte_clear_not_present, allowing optimizations when not-present mapping changes need not be reflected in the hardware TLB for protected page table modes. There is also another case that can use it in the fremap code. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> ---

Add comment and condense code to make use of native_local_ptep_get_and_clear function. Also, it turns out the 2-level and 3-level paging definitions were identical, so move the common definition into pgtable.h Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r b3bbc1b5e085 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h Wed Apr 11 18:23:44 2007 -0700 +++

Add comment and condense code to make use of native_local_ptep_get_and_clear function. Also, it turns out the 2-level and 3-level paging definitions were identical, so move the common definition into pgtable.h Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r b3bbc1b5e085 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h Wed Apr 11 18:23:44 2007 -0700 +++

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Add 5-argument handling for paravirt ops patching of PAE functions. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r dbe11208916f include/asm-i386/paravirt.h --- a/include/asm-i386/paravirt.h Thu Apr 19 11:40:55 2007 -0700 +++ b/include/asm-i386/paravirt.h Thu Apr 19 12:04:16 2007 -0700 @@ -308,10 +308,9 @@ unsigned paravirt_patch_insns(void *site * return value handling from

Add 5-argument handling for paravirt ops patching of PAE functions. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r dbe11208916f include/asm-i386/paravirt.h --- a/include/asm-i386/paravirt.h Thu Apr 19 11:40:55 2007 -0700 +++ b/include/asm-i386/paravirt.h Thu Apr 19 12:04:16 2007 -0700 @@ -308,10 +308,9 @@ unsigned paravirt_patch_insns(void *site * return value handling from

We don't want to read PTEs directly like this after they have been modified, as a lazy MMU implementation of direct page tables may not have written the updated PTE back to memory yet. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: linux-mm@kvack.org --- mm/memory.c | 2 +- 1 file changed, 1 insertion(+), 1

Looks to me like the first series of patches should be OK to post now. I propose that: 001-apply-to-page-range.patch 001a-reboot-use-struct.patch 002-sync-bitops.patch 003-remove-ring0-assumptions.patch 004-abstract-asm.patch 005-cpuid-cleanup.patch unfix-fixmap.patch fixmap-bootparam.patch remove-read-hazard-from-cow.patch pte-clear-not-present.patch

The ptep_establish macro is only used on user-level PTEs, for P->P mapping changes. Since these always happen under protection of the pagetable lock, the strong synchronization of a 64-bit cmpxchg is not needed, in fact, not even a lock prefix needs to be used. We can simply instead clear the P-bit, followed by a normal set. The write ordering is still important to avoid the possibility of