Thanks Andreas ... I also guess this bandwidth is quite big ! ... I will also try with the latest source code ...
To get things more complicated, I also repeat the above experience with only one benchmark (2 CPUs, one idle, one running the benchmark). I expect the run time of the benchmark (not simulation time) be much less than the previous experience (because of cache contention, memory bandwidth contention, etc.) But surprisingly this is not the case! The runtime of blackscholes running concurrently with fluidanimate is 27.217s while the runtime of blackscholes alone is 27.145s. When I look into memory bandwidth stat, It seems that memory bandwidth of fluidanimate and blackscholes are "summed up" and there is not any contention! I'm using MOESI_CMP_token, with recent dev source code of gem5 (I guess it is one month old). Do you agree with me that the difference should be more significant ? Is it related to --sys-clock and --cpu-clock? I am using default values. Thank you in advance On Wed, Nov 6, 2013 at 8:53 AM, Andreas Hansson <[email protected]>wrote: > Hi, > > That does look rather surprising indeed, but it’s not impossible. peakBW > is what the memory controller deduced by looking at the burst time and > interface width (i.e. the peak interface bandwidth). The other stat, > bw_total, is based on the underlying memory model counting all reads and > writes, which includes all the merges in the write buffer and reads that > got their data from the write buffer rather than from the DRAM. If you are > running on a recent version of gem5 (from last Friday), we have > incorporated some additional stats for the controller to see these effects > more clearly. > > What I find more surprising is that with ruby_fs you see so much > bandwidth to the memory controller. When you use ruby_fs the normal memory > controller organisation is a bit contrived (to say the least), and the > mem_ctrls are actually only sitting on the piobus and (as far as I know) > are only used by devices. Thus, the bandwidth you see does sound quite > large. Could some Ruby ninja out there verify that this is right? Also > beware that the “CPU memory”, I.e. The one baked into Ruby, does not care > about the “—men-type” on the command line. > > Andreas > > From: Hossein Nikoonia <[email protected]> > Reply-To: gem5 users mailing list <[email protected]> > Date: Wednesday, 6 November 2013 07:27 > To: gem5 users mailing list <[email protected]> > Subject: [gem5-users] More than peak bw ? > > Dear List, > > I run a system with 2 CPUs to run two concurrent parsec benchmarks. The > problem is that I see a memory controller bandwidth of 6.3 GBps. But the > peakBW is 4.2 GBps ! > > system.mem_ctrls.bw_total::total 6311068945 > # Total bandwidth to/from this memory (bytes/s) > > system.mem_ctrls.peakBW 4266.00 > # Theoretical peak bandwidth in MB/s > > Am I mistaking something? > > Benchmarks are Blackscholes and Fluidanimate. > > > --------------------------------------------------------------------------------------------------------------------------------------------- > Command line: ./build/ALPHA/gem5.fast -d /root/gem5run-large/busy -r -e > configs/example/ruby_fs.py --kernel=alpha-vmlinux_2.6.27-gcc_4.3.4 > --disk-image=linux-parsec-2-1-m5-with-test-inputs.img --topology=Mesh > --mesh-rows=1 --l2cache --l2_size=2MB --num-l2caches=1 --num-dirs=1 > --mem-type=LPDDR2_S4_1066_x32 --mem-size=1024MB > --script=large-17sh.conf/busy.rcS -n 2 > > ------------------------------------------------------------------------------------------------------------------------------------------- > > > and the busy.rcS: > > ------------------------------------------------------------------------------------------------------------------------------------------ > #!/bin/sh > > cd /parsec/install/bin > > /sbin/m5 dumpresetstats 0 100000000 > ./fluidanimate 1 5 /parsec/install/inputs/fluidanimate/in_300K.fluid > /parsec/install/inputs/fluidanimate/out.fluid & > ./blackscholes 1 /parsec/install/inputs/blackscholes/in_64K.txt > /parsec/install/inputs/blackscholes/prices.txt > echo "Done :D" > /sbin/m5 exit > /sbin/m5 exit > > ------------------------------------------------------------------------------------------------------------------------------------------- > > I would appreciate if someone let me know what is wrong with this ... > > Thanks in advance :) > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
