Andrew Morton wrote:
Christoph Lameter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
