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]<mailto:[email protected]>>
Reply-To: gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 6 November 2013 07:27
To: gem5 users mailing list <[email protected]<mailto:[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
