Hi All, I am hitting few issues where LL/SC doesn't provide me mutual exclusion and that results in two threads entering the CR simultaneously. Here below is a snippet of few important transactions of 4 threads in Ruby that justifies this fact. The column after the request type shows the inst seq-num solely used for debugging. So the violation of mutex exclusion arises due to the following events: (1) core 3 finishes Ld-l in line 8, goes to M state and set the locked context to 3 in its private cache, (2) core 0 gets service for its regular load 104633 in line 11/12 and converts the block in core 3's private cache from M->S, (3) Due to core 2's Ld-l, core 3 receives invalidate at line 15 and goes to IM, (4) core 2 finishes its Ld-l in line 17 and set the locked context to 2 in its private cache, (4) Before core 3's St-c invalidates core 2's private cache block in line 23, core 2 gets service for its St-c req from its private cache and enters the CR, (5) subsequently core 3 too enters the CR in line 24
(1) 2289440470500 3 Seq Begin > [0x7e107e68, line 0x7e107e40] ATOMIC 359870 Ld-l from core 3 (2) 2289440475000 2 Seq Begin > [0x7e107e68, line 0x7e107e40] ATOMIC 852948 Ld-l from core 2 (3) 2289440476500 1 L1Cache Inv S>I [0x7e107e40, line 0x7e107e40] (4) 2289440476500 2 L1Cache Store_Atomic S>SM [0x7e107e40, line 0x7e107e40] (5) 2289440477000 1 Seq Begin > [0x7e107e60, line 0x7e107e40] LD 104663 regular load from core 0 (6) 2289440478500 2 L1Cache Inv SM>IM [0x7e107e40, line 0x7e107e40] (7) 2289440481500 3 Seq Done > [0x7e107e68, line 0x7e107e40] 22 cycles 359870 (8) 2289440481500 3 L1Cache Ack_all SM>M [0x7e107e40, line 0x7e107e40] (9) 2289440484500 1 L2Cache L1_GETS MT>MT_IIB [0x7e107e40, line 0x7e107e40] (10) 2289440484500 1 L2Cache L1_GETX MT_IIB>MT_IIB [0x7e107e40, line 0x7e107e40] (11) 2289440487000 3 L1Cache Fwd_GETS M>S [0x7e107e40, line 0x7e107e40] (12) 2289440490000 1 Seq Done > [0x7e107e60, line 0x7e107e40] 26 cycles 104663 (13) 2289440490500 3 Seq Begin > [0x7e107e68, line 0x7e107e40] ATOMIC 359873 St-c from core 3 (14) 2289440492000 3 L1Cache Store_Atomic S>SM [0x7e107e40, line 0x7e107e40] (15) 2289440495000 3 L1Cache Inv SM>IM [0x7e107e40, line 0x7e107e40] (16) 2289440499000 2 Seq Done > [0x7e107e68, line 0x7e107e40] 48 cycles 852948 (17) 2289440499000 2 L1Cache Ack_all SM>M [0x7e107e40, line 0x7e107e40] (18) 2289440502500 1 L2Cache Exclusive_Unblock SS_MB>MT [0x7e107e40, line 0x7e107e40] (19) 2289440503000 1 L2Cache L1_GETX MT>MT_MB [0x7e107e40, line 0x7e107e40] (20) 2289440503000 2 Seq Begin > [0x7e107e68, line 0x7e107e40] ATOMIC 852951 St-c from core 2 (21) 2289440504500 2 Seq Done > [0x7e107e68, line 0x7e107e40] 3 cycles 852951 (22) 2289440504500 2 L1Cache Store_Atomic M>M [0x7e107e40, line 0x7e107e40] (23) 2289440506500 2 L1Cache Fwd_GETX M>I [0x7e107e40, line 0x7e107e40] (24) 2289440509500 3 Seq Done > [0x7e107e68, line 0x7e107e40] 38 cycles 359873 So, the way I get past this issue is by clearing the locked flag in core 3's private cache when the invalidate hits the core 3 in line 15, that will ensure the core 3's store-conditional to fail and thus force it to loop/retry. I can post my changes made in the ruby side for review, if this looks ok. Thanks, Dibakar _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
