Re: page table lock patch V15 [0/7]: overview

Hugh Dickins
2005-01-13T03:09:14Z

On Thu, 13 Jan 2005, Nick Piggin wrote:
> Andrew Morton wrote:
>
> Note that this was with my ptl removal patches. I can't see why Christoph's
> would have _any_ extra overhead as they are, but it looks to me like they're
> lacking in atomic ops. So I'd expect something similar for Christoph's when
> they're properly atomic.
>
> > Look, -7% on a 2-way versus +700% on a many-way might well be a tradeoff we
> > agree to take. But we need to fully understand all the costs and benefits.
>
> I think copy_page_range is the one to keep an eye on.

Christoph's currently lack set_pte_atomics in the fault handlers, yes.
But I don't see why they should need set_pte_atomics in copy_page_range
(which is why I persuaded him to drop forcing set_pte to atomic).

dup_mmap has down_write of the src mmap_sem, keeping out any faults on
that. copy_pte_range has spin_lock of the dst page_table_lock and the
src page_table_lock, keeping swapout away from those. Why would atomic
set_ptes be needed there? Probably in yours, but not in Christoph's.

Hugh