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

[Nick Piggin]

Andrew Morton wrote:

> Christoph Lameter <clameter@xxxxxxx> wrote:
>
> > On Wed, 2 Mar 2005, Andrew Morton wrote:
> >
> >
> > > > Earlier releases back in September 2004 had some pte locking code (and
> > > > AFAIK Nick also played around with pte locking) but that
> > > > was less efficient than atomic operations.
> > > How much less efficient?
> > > Does anyone else have that code around?
> > Nick may have some data. It got far too complicated too fast when I tried
> > to introduce locking for individual ptes. It required bit
> > spinlocks for the pte meaning multiple atomic operations.
>
> One could add a spinlock to the pageframe, or use hashed spinlocking.

I did have a version using bit spin locks in the pte on ia64. That
only works efficiently on architectures who's MMU hardware won't
concurrently update the pte (so you can do non-atomic pte operations
and non-atomic unlocks on a locked pte).

I pretty much solved all the efficiency problems IIRC. Of course
this doesn't work on i386 or x86_64.

Having a spinlock for example per pte page might be another good
option that we haven't looked at.

> > One
> > would have to check for the lock being active leading to significant code
> > changes.
>
> Why?

When using per-pte locks on ia64 for example, the low level code that
walks page tables and sets dirty, accessed, etc bits needs to be made
aware of the pte lock. But Keith made me up a little patch to do this,
and it is pretty simple.


-
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/