question about using a different memory controller

[Veydan Wu]

Hi, all,

In se_fusion.py, memory modules are initiated using SimpleMemory(); when I changed to others like DDR3_1600_x64() which is in the same gem5 folder where simple_memory implemented, I did see the modules initialized and the simulator runs, but no difference in terms of simulation statistics.

It seems ruby use its own MemoryController object, but how does this interfaces with the gem5 memory controller objects like SimpleMemory or DDR3_1600_x64? I need more detailed memory configuration than simple memory, but I doubt that simply changing the ones in se_fusion.py is sufficient. Could anybody give me some hints? Thanks a lot.

--
Regards,

Veydan

[Joel Hestness]

Hi Veydan,

  The short answer is that you can configure the Ruby memory controller pretty accurately from the gem5-gpu command line. I'd recommend reviewing this email thread from this list. If that doesn't clarify what you need, let us know more specifics on what you're trying to model.

  Thanks,

  Joel

--
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Wisconsin - Madison
  http://pages.cs.wisc.edu/~hestness/

[Veydan Wu]

Hi, Joel,

I try to compare the DDR3 and GDDR5 bandwidth and latency difference. I read the email thread you suggest; it may work. But I am not sure if this allows me to do configurations in the many different parameters independently in the memory controller or not, like those in SimpleDRAM.py and DRAMCtrl.py do.

I think more flexibility in using different DRAM controller models would allow for more extensive detailed comparison. I am also interested in how Ruby use/interface the Simple Memory and other DRAM controller models in src/mem/. Could you give me some hints in understanding this? Thanks a lot.

--
Regards,

Veydan

[Joel Hestness]

Hi Veydan,

 

I try to compare the DDR3 and GDDR5 bandwidth and latency difference. I read the email thread you suggest; it may work. But I am not sure if this allows me to do configurations in the many different parameters independently in the memory controller or not, like those in SimpleDRAM.py and DRAMCtrl.py do.

I'm not very familiar with the gem5 classic memory model DRAM models (SimpleDRAM and DRAMCtrl?). However, I'm aware that they model separate bank precharge, and row and column address strobe, which should allow for modeling variants of open-page row-buffer handling policies. The Ruby memory controller models a closed-page row-buffer policy, so the latency of a bank access is always the same (row + column strobe). I'm pretty sure buffering can be modeled in the gem5 classic DRAM models, just like the Ruby model.

Based on the differences, I would be surprised if there are substantial differences in memory performance between gem5 classic memory and Ruby. Check out the memory configuration parameters in gem5-gpu/configs/, GPUConfig.py and GPUMemConfig.py.

I think more flexibility in using different DRAM controller models would allow for more extensive detailed comparison. I am also interested in how Ruby use/interface the Simple Memory and other DRAM controller models in src/mem/. Could you give me some hints in understanding this? Thanks a lot.

I've compared modeling something like GDDR5 vs. DDR3 with the Ruby memory controller, and the performance was substantially similar in most cases. I suspect that any major differences in real hardware memory performance come from the memory scheduling policies rather than an effect of the memory type. I'm not aware that gem5 has much to offer in terms of different scheduling policies, though all of the memory controller code is modifiable.

I'm unsure what you're asking here... In Ruby, the directory controllers have message queues to send and receive memory requests from the Ruby memory controller. I would assume that the gem5 classic memory models communicated between caches and memory using gem5 packets. If you wanted to try to use a gem5 classic memory controller, the interface would probably need to be changed.

Also, it is likely that the question of using Ruby vs. gem5 classic memory controllers has been answered on one of the gem5 lists at some point. I'd recommend doing some searching to see what you can find. I suspect DRAMSim may also be an option.

[Veydan Wu]

Thanks a lot for the reply, Joel, it is interesting to know the GDDR5 and DDR3 with ruby memory controller has quite similar performance. Thanks for the information.

I am not comparing gem5 classic memory with Ruby. I prefer using Ruby alone; but in gem5-gpu/configs/se_fusion.py, there are memory instantiations like:

mem_ctrls = [SimpleMemory(range = cpu_mem_range)]
system.mem_ctrls = mem_ctrls

where simple memory (in src/mem/) is used. If I changed SimpleMemory() to one of the DDR model (in the same folder) as followed,

mem_ctrls = [DDR4_2400_x64(range = cpu_mem_range)]
#mem_ctrls = [SimpleMemory(range = cpu_mem_range)]
system.mem_ctrls = mem_ctrls


then the DDR4 model is instantiated.  And the parameters in gem5-gpu/configs/GPUMemConfig.py seems not to be used at all. For example, the default clock frequency there is 400MHz, but what I read from config.ini is 1200MHz, together with a lot others likes tCL, tRAS, tRFC, not present in GPUMemConfig.py. So, do you think this is the correct modification I need to change to another memory controller or do I need to do something else? Thank you.

--
Regards,

Veydan

[Joel Hestness]

Hi Veydan,

  Note (from the prior email thread on this subject) that the SimpleMemory instantiated with Ruby is simply used as functional backing store. I'm pretty sure that the RubyMemoryController object still gets instantiated and still controls the timing of memory accesses regardless of which memory type you instantiate in mem_ctrls. I'd recommend trying some of the debug flags to get a trace of memory activity and seeing if you can verify what you're looking at. This isn't something we can just answer off-hand.

  Also, again, these questions are better suited for one of the gem5 mailing lists.

  Joel