Running the above experience with 4 CPU and 4 concurrent benchmarks (ALPHA, Ruby, MOESI_CMP_token) results in 12.1 GBps memory controller bandwidth! I guess this is too big for 1 GHz Ruby ... Isn't it?
On Sun, Nov 10, 2013 at 5:59 AM, Hossein Nikoonia <[email protected]>wrote: > Dear list, > > any idea on this? > > > On Wed, Nov 6, 2013 at 9:20 AM, Hossein Nikoonia <[email protected]>wrote: > >> 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
