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

From: Christoph Lameter
Date: Thu Jan 13 2005 - 12:27:08 EST


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.

> Not that I get it what you want it for exactly - the content
> of the pte could change any time when you don't hold page_table_lock, right?

The content of the pte can change anytime the page_table_lock is held and
it may change from cleared to a value through a cmpxchg while the lock is
not held.
-
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/