Re: page table lock patch V15 [0/7]: overview

Linus Torvalds
2005-01-13T17:25:53Z

On Thu, 13 Jan 2005, Christoph Lameter wrote:
>
> On Wed, 13 Jan 2005, Andi Kleen wrote:
>
> > Alternatively you can use a lazy load, checking for changes.
> > (untested)
> >
> > pte_t read_pte(volatile pte_t *pte)
> > {
> > pte_t n;
> > do {
> > n.pte_low = pte->pte_low;
> > rmb();
> > n.pte_high = pte->pte_high;
> > rmb();
> > } while (n.pte_low != pte->pte_low);
> > return pte;
> > }
> >
> > No atomic operations, I bet it's actually faster than the cmpxchg8.
> > There is a small risk for livelock, but not much worse than with an
> > ordinary spinlock.
>
> Hmm.... This may replace the get of a 64 bit value. But here could still
> be another process that is setting the pte in a non-atomic way.

There's a nice standard way of doing that, namely sequence numbers.

However, most of the time it isn't actually faster than just getting the
lock. There are two real costs in getting a lock: serialization and cache
bouncing. The ordering often requires _more_ serialization than a
lock/unlock sequence, so sequences like the above are often slower than
the trivial lock is, at least in the absense of lock contention.

So sequence numbers (or multiple reads) only tend make sense where there
is a _lot_ more reads than writes, and where you get lots of lock
contention. If there are lots of writes, my gut feel (but hey, all locking
optimization should be backed up by real numbers) is that it's better to
have a lock close to the data, since you'll get the cacheline bounces
_anyway_, and locking often has lower serialization costs.

Linus