lkml.org 
[lkml]   [1999]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: spin_unlock optimization(i386)
From
Date
"David Schwartz" <davids@webmaster.com> wrote:
> A speculative read is never "thrown away" if it's needed. It's only thrown
> away if it's not executed (say, due to a conditional branch instruction).

That implies weak ordering if in the process of optimizing (hoisting
the read before the write), the CPU creates a result different from
the case that the instructions were executed in order. I don't think
IA32 is weakly ordered. Our compilers would need to do a lot more
work (as for a MIPS, say).

> > Just flip the diagram to get the case for B.
> >
> > It is my understanding that a read for A that follows a write to B on
> > one processor can move *before* that write, but the read result on A
> > isn't retired until after the write to B occurs (in processor order).
>
> Correct, the read isn't retired, but the value read earlier is the value
> that will be retired when the retire takes place.

Are you sure about that? I think that's the issue this list is trying
to resolve.

> > The processor sees all writes before it's own that have occurred after
> > the read (so it sees A=1), and if any of them touch A, it will
> > invalidated the read on A, *before* its result is retired. The read
> > is redone, and it gets the correct value for A.
>
> The read is never redone. How would the processor possibly know to redo the
> read? And why would it? Are you suggesting that every speculative read be
> redone if any chunk of memory is written to by any processor?

Not every read. In the simplest case, it would throw away any read
that preceded a write, if it sees another write (to any memory
location) coming from another processor before it's write. In the
best case, it would compare the address and size of the read.

Why would it do this? To simplify the compiler writer's job.

If it didn't do this, then how do you explain this expected result,
that C so relies on so very much.

code sequence: C:
write A=0 A = 0;
read A (expect 0) B = A;
write B=A

Your comments suggest this sequence:

read A (A=1) <- speculative read
write A=0
write B=A (B=1) <- use results of speculative read

And this isn't even MP!!

> DS

Drago

-
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:1.335 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site