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

[Christoph Lameter]

On Wed, 2 Mar 2005, Andrew Morton wrote:

> Have the ppc64 and sparc64 people reviewed and acked the change?  (Not a
> facetious question - I just haven't been following the saga sufficiently
> closely to remember).

There should be no change to these arches

> > Because if a pte is locked it should not be used.
>
> Confused.  Why not just spin on the lock in the normal manner?

I thought you wanted to lock the pte? This is realized through a lock bit
in the pte. If that lock bit is set one should not use the pte. Otherwise
the lock is bypassed. Or are you proposing a write lock only?

> If the other relvant architecture people say "we can use this" then perhaps
> we should grin and bear it.  But one does wonder whether some more sweeping
> design change is needed.

Could we at least get the first two patches in? I can then gradually
address the other issues piece by piece.

The necessary more sweeping design change can be found at

http://marc.theaimsgroup.com/?l=linux-kernel&m=110922543030922&w=2

but these may be a long way off. These patches address an urgent issue
that we have with higher CPU counts for a long time and the method used
here has been used for years in our ProPack line.
-
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/