I also checked another run with Ruby in FS mode. I attach the option
'-s' which will switch from timing cpu to detailed cpu. To my surprise,
it end in this case.
$build/ALPHA_MESI_CMP_directory/gem5.opt -d
../exp/2012-12-03-stdsim-mesi-ruby-s configs/example/ruby_fs.py -n 4
--caches --l1d_size=32kB --l1d_assoc=4 --l1i_size=32kB --l1i_assoc=4
--l2cache --l2_size=4MB --l2_assoc=8 --num-l2caches=1 -r 1
--restore-with-cpu=timing --cpu-type=timing *--ruby -s 1 -W 20000000*
I post some outputs here.
.....
**** REAL SIMULATION ****
info: Entering event queue @ 2293289785000. Starting simulation...
.....
Exiting @ tick 2585108236000 because m5_exit instruction encountered
Obviously, MESI can support Ruby well. But I can not explain why gem5
hangs when run with --ruby only.
Best,
Hanfeng
On 12/04/2012 09:27 AM, hanfeng QIN wrote:
Hi,
I download the PARSEC images with pre-compiled benchmark suite from
http://www.cs.utexas.edu/~cart/parsec_m5/
<http://www.cs.utexas.edu/%7Ecart/parsec_m5/>. I extract the
pre-compiled benchmarks into my own disk image made from
util/gem5img.py. According to the document in the above URL, before
entering the ROI, PARSEC will create a checkpoint. So I run the
benchmark (e.g., blackscholes) firstly with configs/common/fs.py as
well as atomic cpu until the checkpoint is generated. Then in second
run, I take configs/common/ruby_fs.py as well as timing cpu and
restore from that checkpoint with detailed measurement of the ROI.
However, during my experiment, I find that when MESI protocol is
equipped, gem5 will hang for many hours after it leaves the ROI. On
the other hand, in MOESI_CMP_directory and MOESI_Hammer cases, the
simulation will end as expected.
Are there any bugs in current MESI protocol implementation to support
Ruby? I am not sure. Wish anyone can give me some suggestions.
Many thanks,
Hanfeng
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
