DRAMSim2 with GEM5 FS mode

[hassahma]

I have integrated DRAMSim2 with Gem5 FS mode but the linux boot process becomes very very slow and benchmark execution is almost not possible due to slow speed. I found out that the slowness is due to the fact that 'DRAMSim2' update callback is called every clock cycles even when there is no read/write request going in to the DRAMSim2.

Please can somebody tell me how to reduce the 'update' call back frequency of DRAMsim2 so that we can use it with gem5 in FS mode. Ideally I would like the update method to be called only when read/write is sent to the DRAMsim2.

Thanks.

[dramninjasUMD]

Unfortunately this is not possible with DRAMSim2's current architecture. Since DRAMSim2 is cycle-based, the update() function is basically the clock tick function. Even if there are no requests, there is still state being updated in the DRAM (for example, refresh).

You'd pretty much have to re-write the simulator from scratch to accomplish this.

[dramninjasUMD]

After speaking with a colleague in our group, he told me that there have been other people who have complained about the speed of DRAMSim2. The only benchmarking I did was with MARSSx86 and the DRAMSim2 overhead wasn't that significant so I never really bothered to optimize (you know the adage about premature optimization).

Over the weekend I plan on doing some work on DRAMSim2 and I will try to run it through a profiler to see if I can squeeze some performance out of it.

[hassahma]

Thanks for the details. If I run gem5 in FS mode (atomic cpu) with integrated DRAMSim2 then the linux doesn't boot up even in 8 hours. But if I comment out the statement "channels[i]->update();" in actual_update method then linux boots in 3 minutes.

In Atomic cpu mode, there is no memory traffic, so all the overhead is due to background energy processing dramsim2 on each clock tick I think. I was thinking of changing dramsim2 in a way that, I only increase the cycle count on each clock tick. But when a memory access comes in, then I call 'update' method in MemoryController.cpp in a loop that iterates through the number of clock cycles since last memory access. I tried that but it ranks throgh the error that they are not in valid state.

[debiprasannasahoo]

Hi,

I was also trying to integrate DRAMSim2 (revision 2.2.2) with gem5 (revision : 10005). I found a similar behavior as discussed above. After the integration, I configured to run the PARSEC benchmark in fs mode and it executed for ever even for max inst set to a very low value. I tried to comment out "channels[i]->update();" but the simulation didn't stop rather hanged.

Can somebody tell me if the above problem was resolved or any other alternative.

Thanks, Debiprasanna