Re: spin_unlock optimization(i386)

Jeff V. Merkey (jmerkey@timpanogas.com)
Tue, 23 Nov 1999 22:26:42 -0700

Jamie Lokier wrote:
>
>
> You on the other hand are saying that the spin-unlock write may not be
> seen immediately by other processors. That's ok. It adds an occasional
> delay, but doesn't break the assumption that operations in the spinlock
> context are all seen (reads and writes) by other processors when the
> spinlock is seen to be locked.
>
> It seems to me your observation is consistent with what Erich has to
> say, and that Erich is saying the spin-unlock optimisation is safe.
> Though it's not obvious from the processor manual.

Correct. The optimization will work just fine, and it increases
performance significantly. After the LOCK# lead gets pulled, you will
see tons of non-cacheable memory references on an analyzer as the
processor re-fills the pipelines and internal write buffers. It's
heavier than a TLB flush. My observations indicated that the PPro would
loose 24+ clock cycles (and depending on the Memory Bus Controler
chipset on your motherboard, even more) of time to recover after a LOCK#
assertion.

NetWare 4/5 uses this optimization in it's spinlocks. It works fine and
boosts performance. On Intel machines, LOCK#'s are heavier than they
need to be becuase of all the issues Intel has with people writing
self-modifying code (about 60% of their errata deals with this problem).

Jeff

>
> -- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/