----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3149/#review7377 -----------------------------------------------------------
src/mem/ruby/system/Sequencer.cc (line 393) <http://reviews.gem5.org/r/3149/#comment6226> There's no reason that I can see why this should be a std::map. The mandatory_q_ptr that is passed in is not used by anything at all. (The only checks now are on the address and there is no action taken on the mandatory_q. Maybe I am missing something?) Can we change the tracking structure to reflect that this is really a vector of addresses for the memory controller that we should be checking instead of a map? Actually, there's only a single address with this new modification since the request will be nack'd back to the requester. - Brandon Potter On Oct. 9, 2015, 3:15 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3149/ > ----------------------------------------------------------- > > (Updated Oct. 9, 2015, 3:15 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11157:65d87638830f > --------------------------- > ruby: Fix block_on behavior > > Ruby's controller block_on behavior aimed to block MessageBuffer requests into > SLICC controllers when a Locked_RMW was in flight. Unfortunately, this > functionality only partially works: When non-Locked_RMW memory accesses are > issued to the sequencer to an address with an in-flight Locked_RMW, the > sequencer may pass those accesses through to the controller. At the > controller, > a number of incorrect activities can occur depending on the protocol. In > MOESI_hammer, for example, an intermediate IFETCH will cause an L1D to L2 > transfer, which cannot be serviced, because the block_on functionality blocks > the trigger queue, resulting in a deadlock. Further, if an intermediate store > arrives (e.g. from a separate SMT thread), the sequencer allows the request > through to the controller, and the atomicity of the Locked_RMW may be broken. > > To avoid these problems, disallow the Sequencer from passing any memory > accesses to the controller besides Locked_RMW_Write when a Locked_RMW is in- > flight. > > > Diffs > ----- > > src/mem/ruby/slicc_interface/AbstractController.hh bd894d2bdd7c > src/mem/ruby/slicc_interface/AbstractController.cc bd894d2bdd7c > src/mem/ruby/system/Sequencer.cc bd894d2bdd7c > > Diff: http://reviews.gem5.org/r/3149/diff/ > > > Testing > ------- > > Considered many other potential solutions on gem5-gpu email list, which seem > unlikely to function as desired: > https://groups.google.com/forum/#!topic/gem5-gpu-dev/RQv4SxIKv7g > > Found reproducible version of the IFETCH bug with gem5 11139:bd894d2bdd7c > (using the xsave disable patch in this email thread: > http://comments.gmane.org/gmane.comp.emulators.m5.devel/24558 ) > > Reproducible command line: ../build/X86_MOESI_hammer/gem5.opt > --outdir=$outdir ../configs/example/fs.py --ruby --cpu-type=detailed --caches > --num-cpus=4 --script ../configs/boot/hack_back_ckpt.rcS --kernel > ../../full_system_files/binaries/x86_64-vmlinux-2.6.28.4-smp > > Verified that the patch fixes the reproducible bug and tested that booting > Linux works with O3CPU and numerous other system configurations. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
