lkml.org 
[lkml]   [1999]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: spin_unlock optimization(i386)


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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.032 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site