Re: Page fault scalability patch V18: Drop first acquisition of ptl

Paul Mackerras
2005-03-03T05:00:10Z

Andrew Morton writes:

> But if the approach which these patches take is not suitable for these
> architectures then they have no solution to the scalability problem. The
> machines will perform suboptimally and more (perhaps conflicting)
> development will be needed.

We can do a pte_cmpxchg on ppc64. We already have a busy bit in the
PTE and do most operations atomically, in order to ensure that we
don't get races or inconsistencies due to accesses to the PTE by the
low-level hash_page() routine (which instantiates a hardware PTE in
the hardware hash table based on a Linux PTE), because it already
accesses the linux page tables without taking the mm->page_table_lock.

However, there are other developments we are considering in this area:
notably Ben wants to change things so that when we invalidate a Linux
PTE we leave it busy until we actually remove the hardware PTE from
the hash table. Also we are looking forward to DaveM's patch which
will change the generic MM code to give us the mm and address on all
PTE operations, which will simplify some things for us. I don't
really want to have to think about pte_cmpxchg until those other
things are sorted out.

More generally, I would be interested to know what sorts of
applications or benchmarks show scalability problems on large machines
due to contention on mm->page_table_lock.

Paul.