Hi,
I am not a Ruby user myself, so I don’t dare say what is expected or not. What
memory controller are you referring to? Ruby has a built in memory controller
that scales one way or another with the network size.
The “classic” SimpleDRAM controller behaves as I described earlier, with the
peak bandwidth referring to the interface.
Andreas
From: Hossein Nikoonia <[email protected]<mailto:[email protected]>>
Reply-To: gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Sunday, November 10, 2013 at 6:39 AM
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
Subject: Re: [gem5-users] More than peak bw ?
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]<mailto:[email protected]>> wrote:
Dear list,
any idea on this?
On Wed, Nov 6, 2013 at 9:20 AM, Hossein Nikoonia
<[email protected]<mailto:[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]<mailto:[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]<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]<mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- 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
