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

[David S. Miller]

On Thu, 3 Mar 2005 16:00:10 +1100
Paul Mackerras <paulus@xxxxxxxxx> wrote:

> 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 really can't make use of this on sparc64.  Unlike ppc64 I don't
have the hash table issue (although sparc64 TLB's have a hash lookup
helping mechanism in hardware, which we ignore since virtually mapped
linear page tables are faster than Sun's bogus TSB table scheme).

I make all real faults go through the handle_mm_fault() path so all
page table modifications are serialized by the page table lock.
The TLB miss handlers never modify PTEs, not even to update access
and dirty bits.

Actually, I guess I could do the pte_cmpxchg() stuff, but only if it's
used to "add" access.  If the TLB miss handler races, we just go into
the handle_mm_fault() path unnecessarily in order to synchronize.

However, if this pte_cmpxchg() thing is used for removing access, then
sparc64 can't use it.  In such a case a race in the TLB handler would
result in using an invalid PTE.  I could "spin" on some lock bit, but
there is no way I'm adding instructions to the carefully constructed
TLB miss handler assembler on sparc64 just for that :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/