Hi Mitch,
I wonder if this happens in the steady state? With the implementation the store-set predictor should predict that the store is going to conflict the load and order them. Perhaps that isn't getting trained correctly with LLSC ops. You really don't want to mark the ops as serializing as that slows down the cpu quite a bit. Thanks, Ali On 26.09.2012 13:14, Mitch Hayenga wrote: > Background: > I have a non-o3, out of order CPU implemented on gem5. Since I don't have a checker implemented yet, I tend to diff committed instructions vs o3. Yesterday's patches caused a few of these diffs change because of load-linked/store-conditional behavior (better prediction on data ops that write the PC leads to denser load/store scheduling). > Issue: > It seems O3's own loads/stores can cause its load-linked/store-conditional pair to fail. Previously running a single core under SE, every load-linked/store-conditional pair would succeed. Now I'm observing them failing 21% of the time (on single-threaded programs). Although the programs functionally work given how the LL/SC is coded currently, I think this points to the fact LL/SC should be handled slightly differently. > Example: > From "Hello World" on ARM+O3+Single Core+SE+Classic Memory that shows this. This contains locks because I assume the C++ library is thread-safe. > http://pastebin.com/sNjTPBWY [1] > The O3 CPU is effectively doing a "Test and TestAndSet". It looks like the load for the Test and the load-linked for the race for memory. Also, the CPU has a pending writeback to the same line. So effectively, the TestAndSet fails (haven't dug into it to determine if it was the racing load or the writeback that caused the failure). > Given this, shouldn't load-linked (in this case ldrex) instructions be marked as non-speculative (or one of the other flags) so that they don't contend with earlier operations? > Thanks. Links: ------ [1] http://pastebin.com/sNjTPBWY
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
