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

Nick Piggin
2005-01-13T03:46:51Z

Hugh Dickins wrote:
> 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.
>

I was more thinking of atomic pte reads there. I had for some reason
thought that dup_mmap only had a down_read of the mmap_sem. But even if
it did only down_read, a further look showed this wouldn't have been a
problem for Christoph anyway. That dim light-bulb probably changes things
for my patches too; I may be able to do copy_page_range with fewer atomics.

I'm still not too sure that all places read the pte atomically where needed.
But presently this is not a really big concern because it only would
really slow down i386 PAE if anything.