Re: pagefault scalability patches

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2005-08-17 at 17:43 -0700, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:

> d) the fact that some architectures will be using atomic pte ops and
>    others will be using page_table_lock in core MM code.
> 
>    Using different locking/atomicity schemes in different architectures
>    has obvious complexity and test coverage drawbacks.
> 
>    Is it still the case that some architectures must retain the
>    page_table_lock approach because they use it to lock other arch-internal
>    things?

Yes. The ppc64 case for example isn't trivial due to the difference
between manipulating the linux page tables, and sync'ing the hash
table. 

If we go toward non-PTL page faults, I'll need to review all the hash
management code path that assume that thanks to the PTL, nothing will be
happening to the page tables between a PTL update and the matching hash
flush.

I think it shouldn't be too bad though as long as we are only ever doing
that to fill a previously !present PTE (no hash flush necessary). If we
ever want that for the COW case as well (where set_pte is called for an
already present PTE), then things would get more complicated and I may
have to rely more on the per-PTE locking mecanism we have (which is
currently mostly used to avoid duplicates in the hash table).

Ben.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>