Re: [patch 3/5] remove ptep_test_and_clear_dirty and ptep_clear_flush_dirty.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux