lkml.org 
[lkml]   [1999]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: spin_unlock optimization(i386)
Ingo Molnar wrote:
>
> my (fixed) test code doesnt show any causality violation. Manfred's code
> is a complex simulation of one given Linux code sequence, Manfred are you
> sure it's not buggy?
>
I looked at your program [the version from this morning, 11:34], and
this test checks for write ordering, not for the causality problem:

CPU1:
STORE A
STORE B
STORE A
STORE B
...

all other CPU's:
LOAD B
LOAD A
if (a<b) BUG()
This cannot happen:
- stores are never reordered, ie cpu1 sends them to the system bus in
the same order as they are executed.
- if a cpu sees one write operation on the system bus, then it's
guaranteed that it has seen all previous write operations.

---------
You you please look at my program?
if you want to trigger the bug, then you must _both_ read and write data
from one cpu. If one cpu writes data, and one cpu reads data, then
you'll never trigger the problem.

the cpu executes read before a following write, and on UP this is
transparent due to the "store buffer forwarding". But the store buffer
is private to each cpu, and thus this fails on SMP.

The problem has _nothing_ to do with the cache lines,..: the cache
protocol enforces the coherency, the problem lies _before_ the data
enters the cache.

--
Manfred


-
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    [from the cache]
©2003-2011 Jasper Spaans