01 Oct, 2006

3 commits

  • Now that ptep_establish has a definition in PAE i386 3-level paging code, the
    only paging model which is insane enough to have multi-word hardware PTEs
    which are not efficient to set atomically, we can remove the ghost of
    set_pte_atomic from other architectures which falesly duplicated it, and
    remove all knowledge of it from the generic pgtable code.

    set_pte_atomic is now a private pte operator which is specific to i386

    Signed-off-by: Zachary Amsden
    Cc: Rusty Russell
    Cc: Jeremy Fitzhardinge
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     
  • Implement lazy MMU update hooks which are SMP safe for both direct and shadow
    page tables. The idea is that PTE updates and page invalidations while in
    lazy mode can be batched into a single hypercall. We use this in VMI for
    shadow page table synchronization, and it is a win. It also can be used by
    PPC and for direct page tables on Xen.

    For SMP, the enter / leave must happen under protection of the page table
    locks for page tables which are being modified. This is because otherwise,
    you end up with stale state in the batched hypercall, which other CPUs can
    race ahead of. Doing this under the protection of the locks guarantees the
    synchronization is correct, and also means that spurious faults which are
    generated during this window by remote CPUs are properly handled, as the page
    fault handler must re-check the PTE under protection of the same lock.

    Signed-off-by: Zachary Amsden
    Signed-off-by: Jeremy Fitzhardinge
    Cc: Rusty Russell
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     
  • 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
    Signed-off-by: Jeremy Fitzhardinge
    Cc: Rusty Russell
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     

26 Sep, 2006

1 commit

  • Parsing generic pgtable.h in assembler is simply crazy. None of this file is
    needed in assembler code, and C inline functions and structures routine break
    one or more different compiles.

    Signed-off-by: Zachary Amsden
    Signed-off-by: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rusty Russell
     

02 Jun, 2006

1 commit

  • If we move a mapping from one virtual address to another,
    and this changes the virtual color of the mapping to those
    pages, we can see corrupt data due to D-cache aliasing.

    Check for and deal with this by overriding the move_pte()
    macro. Set things up so that other platforms can cleanly
    override the move_pte() macro too.

    Signed-off-by: David S. Miller

    David S. Miller
     

07 Nov, 2005

1 commit

  • Fix more include file problems that surfaced since I submitted the previous
    fix-missing-includes.patch. This should now allow not to include sched.h
    from module.h, which is done by a followup patch.

    Signed-off-by: Tim Schmielau
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

30 Oct, 2005

1 commit


28 Sep, 2005

1 commit

  • Move the ZERO_PAGE remapping complexity to the move_pte macro in
    asm-generic, have it conditionally depend on
    __HAVE_ARCH_MULTIPLE_ZERO_PAGE, which gets defined for MIPS.

    For architectures without __HAVE_ARCH_MULTIPLE_ZERO_PAGE, move_pte becomes
    a noop.

    From: Hugh Dickins

    Fix nasty little bug we've missed in Nick's mremap move ZERO_PAGE patch.
    The "pte" at that point may be a swap entry or a pte_file entry: we must
    check pte_present before perhaps corrupting such an entry.

    Patch below against 2.6.14-rc2-mm1, but the same bug is in 2.6.14-rc2's
    mm/mremap.c, and more dangerous there since it's affecting all arches: I
    think the safest course is to send Nick's patch and Yoichi's build fix and
    this fix (build tested) on to Linus - so only MIPS can be affected.

    Signed-off-by: Nick Piggin
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

05 Sep, 2005

1 commit

  • Add a new accessor for PTEs, which passes the full hint from the mmu_gather
    struct; this allows architectures with hardware pagetables to optimize away
    atomic PTE operations when destroying an address space. Removing the
    locked operation should allow better pipelining of memory access in this
    loop. I measured an average savings of 30-35 cycles per zap_pte_range on
    the first 500 destructions on Pentium-M, but I believe the optimization
    would win more on older processors which still assert the bus lock on xchg
    for an exclusive cacheline.

    Update: I made some new measurements, and this saves exactly 26 cycles over
    ptep_get_and_clear on Pentium M. On P4, with a PAE kernel, this saves 180
    cycles per ptep_get_and_clear, for a whopping 92160 cycles savings for a
    full address space destruction.

    pte_clear_full is not yet used, but is provided for future optimizations
    (in particular, when running inside of a hypervisor that queues page table
    updates, the full hint allows us to avoid queueing unnecessary page table
    update for an address space in the process of being destroyed.

    This is not a huge win, but it does help a bit, and sets the stage for
    further hypervisor optimization of the mm layer on all architectures.

    Signed-off-by: Zachary Amsden
    Cc: Christoph Lameter
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     

22 Jun, 2005

1 commit

  • It's common practice to msync a large address range regularly, in which
    often only a few ptes have actually been dirtied since the previous pass.

    sync_pte_range then goes much faster if it tests whether pte is dirty
    before locating and accessing each struct page cacheline; and it is hardly
    slowed by ptep_clear_flush_dirty repeating that test in the opposite case,
    when every pte actually is dirty.

    But beware, s390's pte_dirty always says false, since its dirty bit is kept
    in the storage key, located via the struct page address. So skip this
    optimization in its case: use a pte_maybe_dirty macro which just says true
    if page_test_and_clear_dirty is implemented.

    Signed-off-by: Abhijit Karmarkar
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Abhijit Karmarkar
     

20 Apr, 2005

1 commit

  • ia64 and sparc64 hurriedly had to introduce their own variants of
    pgd_addr_end, to leapfrog over the holes in their virtual address spaces which
    the final clear_page_range suddenly presented when converted from pgd_index to
    pgd_addr_end. But now that free_pgtables respects the vma list, those holes
    are never presented, and the arch variants can go.

    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds