lkml.org 
[lkml]   [2010]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH] mips,mm: Reinstate move_pte optimization
    Date
    CC to mips folks.

    > If something like this or your replacment does go forward,
    > then I think that test is better inside the "if (!page->mapping)"
    > below. Admittedly that adds even more mm-dependence here (relying
    > on a zero page to have NULL page->mapping); but isn't page_to_pfn()
    > one of those functions which is trivial on many configs but expensive
    > on some? Better call it only in the rare case that it's needed.
    >
    > Though wouldn't it be even better not to use is_zero_pfn() at all?
    > That was convenient in mm/memory.c because it had the pfn or pte right
    > at hand, but here a traditional (page == ZERO_PAGE(address)) would be
    > more efficient.
    >
    > Which would save having to move is_zero_pfn() from mm/memory.c
    > to include/linux/mm.h - I'd prefer to keep it private if we can.
    > But for completeness, this would involve resurrecting the 2.6.19
    > MIPS move_pte(), which makes sure mremap() move doesn't interfere
    > with our assumptions. Something like
    >
    > #define __HAVE_ARCH_MOVE_PTE
    > pte_t move_pte(pte_t pte, pgprot_t prot, unsigned long old_addr,
    > unsigned long new_addr)
    > {
    > if (pte_present(pte) && is_zero_pfn(pte_pfn(pte)))
    > pte = mk_pte(ZERO_PAGE(new_addr), prot);
    > return pte;
    > }
    >
    > in arch/mips/include/asm/pgtable.h.

    I agree with resurrecting mips move_pte. At least your patch
    passed my cross compile test :)

    Ralf, can you please review following patch?


    ======================================================
    Subject: [PATCH] mips,mm: Reinstate move_pte optimization
    From: Hugh Dickins <hugh.dickins@tiscali.co.uk>

    About three years ago, we removed mips specific move_pte by commit
    701dfbc1cb (mm: mremap correct rmap accounting). because it is only
    small optimization and it has bug.

    However new zero-page thing doesn't have such problem and behavior
    consistency of mremap have worth a bit.

    This patch reinstate it.

    Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: Nick Piggin <npiggin@suse.de>
    Cc: Carsten Otte <cotte@de.ibm.com>
    ---
    arch/mips/include/asm/pgtable.h | 8 ++++++++
    1 files changed, 8 insertions(+), 0 deletions(-)

    diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
    index 1854336..6ad2f73 100644
    --- a/arch/mips/include/asm/pgtable.h
    +++ b/arch/mips/include/asm/pgtable.h
    @@ -387,6 +387,14 @@ static inline int io_remap_pfn_range(struct vm_area_struct *vma,
    remap_pfn_range(vma, vaddr, pfn, size, prot)
    #endif

    +#define __HAVE_ARCH_MOVE_PTE
    +pte_t move_pte(pte_t pte, pgprot_t prot, unsigned long old_addr, unsigned long new_addr)
    +{
    + if (pte_present(pte) && is_zero_pfn(pte_pfn(pte)))
    + pte = mk_pte(ZERO_PAGE(new_addr), prot);
    + return pte;
    +}
    +
    #include <asm-generic/pgtable.h>

    /*
    --
    1.6.5.2




    \
     
     \ /
      Last update: 2010-01-07 07:35    [W:0.027 / U:0.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site