> On May 3, 2014, 6:19 a.m., Nilay Vaish wrote: > > I tried running the regression tests. They fail because some clock > > domain you assume is missing in the test configurations. Here is output > > from one of the regression tests: > > > > Traceback (most recent call last): > > File "<string>", line 1, in <module> > > File "/scratch/nilay/GEM5/gem5/src/python/m5/main.py", line 388, in main > > exec filecode in scope > > File "tests/run.py", line 180, in <module> > > execfile(joinpath(tests_root, 'configs', test_filename + '.py')) > > File "tests/configs/simple-timing-ruby.py", line 82, in <module> > > Ruby.create_system(options, system) > > File "/scratch/nilay/GEM5/gem5/configs/ruby/Ruby.py", line 114, in > > create_system > > % protocol) > > File "<string>", line 1, in <module> > > File "/scratch/nilay/GEM5/gem5/configs/ruby/MESI_Two_Level.py", line 98, > > in create_system > > clk_domain=system.cpu_clk_domain, > > File "/scratch/nilay/GEM5/gem5/src/python/m5/SimObject.py", line 736, in > > __getattr__ > > raise AttributeError, err_string > > AttributeError: object 'System' has no attribute 'cpu_clk_domain' > > (C++ object is not yet constructed, so wrapped C++ methods are > > unavailable.) > > > > > > > > You would have to update the scripts in tests/configs appropriately. > > > > Andreas Hansson wrote: > Is there any chance we could get this resolved and pushed?
It seems Emilio is not going to put effort into this. I'll take over this patch and carry out the required changes. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2218/#review5080 ----------------------------------------------------------- On April 22, 2014, 6:37 p.m., Emilio Castillo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2218/ > ----------------------------------------------------------- > > (Updated April 22, 2014, 6:37 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > This patch fixes the se.py script by adding the ruby clock domain. > > This would cause the ruby clock domain to be set at 1GHz by default. > Running simulations with the cpu clock set at 2GHz or 1GHz will output the > same time results and could distort > power measurements. > > The patch also sets the clock domain for each coherence protocol. Now the L1 > controllers and the Sequencer shares the cpu clock domain, > while the rest of the components use the ruby clock domain. > > Thanks to Mr. Nilay Vaish for his help while figuring out what was happening. > > > Diffs > ----- > > configs/example/se.py 7d7f635e7447 > configs/ruby/MESI_Three_Level.py 7d7f635e7447 > configs/ruby/MESI_Two_Level.py 7d7f635e7447 > configs/ruby/MI_example.py 7d7f635e7447 > configs/ruby/MOESI_CMP_directory.py 7d7f635e7447 > configs/ruby/MOESI_CMP_token.py 7d7f635e7447 > configs/ruby/MOESI_hammer.py 7d7f635e7447 > > Diff: http://reviews.gem5.org/r/2218/diff/ > > > Testing > ------- > > This was tested using a timing cpu with a code that is not memory or I/O > bounded such as: > > #include <math.h> > #include <stdio.h> > > void main() > { > float var=0.0f; > int i; > for (i=0;i<800000;i++) > var=exp(var); > printf("var %f\n",var); > } > > If CPU freq. is halved from 2GHz to 1GHz, execution time is also expected to > decrease. > (This has been verified with the classic memory model). > > > build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 -c ./a.out > --cpu-type=timing --caches --cpu-clock=2GHz > > sim_seconds 0.076027 # > Number of seconds simulated > system.cpu0.numCycles 152035861 > > > build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 -c ./a.out > --cpu-type=timing --caches --cpu-clock=1GHz > > sim_seconds 0.152036 > system.cpu0.numCycles 152054288 > > > However if ruby is used (with the se.py fixed by adding the ruby clock), > execution time will be the same at 2GHz and 1GHz for the cpu. > > build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 --ruby > --num-l2cache=2 --num-dirs=2 -c ./a.out --cpu-clock=2GHz > sim_seconds 0.304070 > system.cpu0.numCycles 608140702 > > build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 --ruby > --num-l2cache=2 --num-dirs=2 -c ./a.out --cpu-clock=1GHz > sim_seconds 0.304070 # > Number of seconds simulated > system.cpu0.numCycles 304070351 > > > Suppose the cache access cycles are set to 2 cycles at 2GHz, if the CPU freq. > is also set to 2GHz then a memory access will take > 2 cycles, even for ins. fetch in the simple cpus. > > If the CPU freq is now lowered to 1GHz, each memory access to the L1's will > take 1 cycle seen from the cpu side. > Ins. fetch will take now 1 Cycle, thus the number of execution cycles will be > exactly twice more in the 2GHz cpu. > > 608140702/304070351=2.0 > > This patch fixes it with an approach similar taken in the classic memory > model, where the l1 controllers are set to the cpu clock domain. > > > Thanks, > > Emilio Castillo > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
