On Sun, 25 Mar 2007, David Rientjes wrote:
> Add ptep_test_and_clear_{dirty,young} to i386.  They advertise that they
> have it and there is at least one place where it needs to be called
> without the page table lock: to clear the accessed bit on write to

Without the page table lock??

> /proc/pid/clear_refs.
> 
> ptep_clear_flush_{dirty,young} are updated to use the new functions.  The
> overall net effect to current users of ptep_clear_flush_{dirty,young} is
> that we introduce an additional branch.

We need to Cc Zach on this: git blame indicates it was he who replaced
i386's ptep_test_and_clear_{dirty,young} by that "We don't actually
have these" comment - it looks a bit as if what you want to do might
violate the assumptions he wants to make, but I don't grasp it.

Hugh

> 
> Cc: Hugh Dickins <[EMAIL PROTECTED]>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
> ---
>  include/asm-i386/pgtable.h |   25 +++++++++++++++++--------
>  1 files changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/include/asm-i386/pgtable.h b/include/asm-i386/pgtable.h
> --- a/include/asm-i386/pgtable.h
> +++ b/include/asm-i386/pgtable.h
> @@ -283,12 +283,23 @@ do {                                                    
>                 \
>       }                                                               \
>  } while (0)
>  
> -/*
> - * We don't actually have these, but we want to advertise them so that
> - * we can encompass the flush here.
> - */
>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
> +static inline int ptep_test_and_clear_dirty(struct vm_area_struct *vma,
> +                                         unsigned long addr, pte_t *ptep)
> +{
> +     if (!pte_dirty(*ptep))
> +             return 0;
> +     return test_and_clear_bit(_PAGE_BIT_DIRTY, &ptep->pte_low);
> +}
> +
>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
> +static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
> +                                         unsigned long addr, pte_t *ptep)
> +{
> +     if (!pte_young(*ptep))
> +             return 0;
> +     return test_and_clear_bit(_PAGE_BIT_ACCESSED, &ptep->pte_low);
> +}
>  
>  /*
>   * Rules for using ptep_establish: the pte MUST be a user pte, and
> @@ -305,9 +316,8 @@ do {                                                      
>                 \
>  #define ptep_clear_flush_dirty(vma, address, ptep)                   \
>  ({                                                                   \
>       int __dirty;                                                    \
> -     __dirty = pte_dirty(*(ptep));                                   \
> +     __dirty = ptep_test_and_clear_dirty((vma), (address), (ptep));  \
>       if (__dirty) {                                                  \
> -             clear_bit(_PAGE_BIT_DIRTY, &(ptep)->pte_low);           \
>               pte_update_defer((vma)->vm_mm, (address), (ptep));      \
>               flush_tlb_page(vma, address);                           \
>       }                                                               \
> @@ -318,9 +328,8 @@ do {                                                      
>                 \
>  #define ptep_clear_flush_young(vma, address, ptep)                   \
>  ({                                                                   \
>       int __young;                                                    \
> -     __young = pte_young(*(ptep));                                   \
> +     __young = ptep_test_and_clear_young((vma), (address), (ptep));  \
>       if (__young) {                                                  \
> -             clear_bit(_PAGE_BIT_ACCESSED, &(ptep)->pte_low);        \
>               pte_update_defer((vma)->vm_mm, (address), (ptep));      \
>               flush_tlb_page(vma, address);                           \
>       }                                                               \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to