[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1183447598.9766.12.camel@localhost>
Date: Tue, 03 Jul 2007 09:26:38 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: Zachary Amsden <zach@...are.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Hugh Dickins <hugh@...itas.com>
Subject: Re: [patch 3/5] remove ptep_test_and_clear_dirty and
ptep_clear_flush_dirty.
On Mon, 2007-07-02 at 18:29 -0700, Zachary Amsden wrote:
> > -static inline int
> > -ptep_test_and_clear_dirty (struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
> > -{
> > -#ifdef CONFIG_SMP
> > - if (!pte_dirty(*ptep))
> > - return 0;
> > - return test_and_clear_bit(_PAGE_D_BIT, ptep);
> > -#else
> > - pte_t pte = *ptep;
> > - if (!pte_dirty(pte))
> > - return 0;
> > - set_pte_at(vma->vm_mm, addr, ptep, pte_mkclean(pte));
> > - return 1;
> > -#endif
> > -}
>
> I've not followed all the changes lately - what is the current protocol
> for clearing dirty bit? Is it simply pte_clear followed by set or is it
> not done at all? At least for i386 and virtualization, we had several
> optimizations to the test_and_clear path that are not possible with a
> pte_clear / set_pte approach.
Imho with a sequence of ptep_get_and_clear, pte_wrprotect, set_pte_at.
One of the reasons why ptep_test_and_clear_dirty doesn't make sense
anymore is the shared dirty page tracking. You never just test and clear
the dirty bit, the latest code always sets the write protect bit as
well.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists