Ramulator runs forever

[stevekulick]

I tracked it down to this snippet from Controller.h. I grant that read-write arbitration is complex, and an always on MC might be OK like this. (there is no harm in leaving a few buffered writes around). But the simulator never completes and never prints stats. A real MC that did power management would like to purge them.

P.S. You should expose the debug option to print the commands to STDOUT. It would have taken me half the time to track this down.

/ 3. Should we schedule writes? / if (!write_mode) { // yes -- write queue is almost full or read queue is empty if (writeq.size() >= int(0.8 writeq.max) || readq.size() == 0) // Hasan did not appear to test this; writes are never purged, sim goes forever /|| readq.size() == 0) // Hasan: Switching to write mode when there are just a few // write requests, even if the read queue is empty, incurs a lot of overhead. // Commented out the read request queue empty condition */ write_mode = true; }

[stevekulick]

If you don't mind the question, Is this code in good shape otherwise?

[arthasSin]

Hi Steve, Thanks for the feedback. The latest commit fixes the issue you were seeing when running Ramulator in "Memory Trace Driven" mode. The completion condition for the input trace in the "Memory Trace Driven" mode is having all traces issued to the memory controller and draining the read and write requests in the request queues. The latest changes made the controller reluctant to service write requests if there are only a few in the write queue, with the aim of improving the performance by reducing the read-write turnaround overhead. However, those changes led to the issue that you experienced.

We fixed the issue by forcing write requests to be drained when all memory requests in the input trace are issued to the memory controller. We force write requests by setting the "write queue high watermark" (previously magic number 0.8) to 0, which makes the controller switch to write mode even if there is only a single request in the write queue.

The bug only affected the "Memory Trace Driven" mode. Ramulator should be stable when used with "CPU Trace Driven" mode or as a memory subsystem backend for Gem5.

To answer your second question, we believe, in general, Ramulator is in a good shape, although it lacks some features that may make Ramulator easier to work with and debug. We use it for our own research and we have a plan for adding new features over time.

[stevekulick]

I am glad to hear this code is still being maintained. I also ran into compile problems when building on Ubuntu. g++-5 -O3 -std=c++11 -g -Wall -DRAMULATOR -o ramulator src/Main.cpp obj/Controller.o ........ src/Main.cpp:94:26: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for(int c = 0; c < proc.cores.size(); c++){

So I made these changes to Main.cpp. I am not a real programmer, so I am only guessing this is better:

< for(unsigned int c = 0; c < proc.cores.size(); c++){

cheers!