[Question] Cache organization, overview of functions in the memory system, and measuring memory latency about scarab HOT 4 CLOSED

This is Heiner who had the original question. subscribing to this thread.

from scarab.

Hi!
1)
In Scarab we have the ICache/Dcache, MLC(mid-level cache), and the L1. These correspond to the L1 I/D, unified L2, and unifed L3 in a typical three-level cache hierarchy.
However, recent users of Scarab have usually disabled the MLC, leaving a two-level data cache hierarchy with the Dcache and L1. Thus the MLC have not been used and tested in a long time. The MLC currently will NOT work as it is, because you will encounter an assert failure in new_mem_req() in memory.c. I have briefly looked at this assert, and it seems safe to remove. Once the assert is removed, the MLC will run without crashing. I have run some studies with the MLC enabled, and it appears to work, but I have frequently found that performance (i.e., IPC) is lower with the MLC enabled, when compared to the two-level Dcache/L1 configuration. I don't yet have a good grasp on why this is yet, but it is something I will look into.

The highest level function is update_memory() under src/memory/memory.c
You can ignore perf_pred_cycle(), pref_update(), and update_on_chip_memory_stats().
update_memory_queues() goes through the queues which hold requests to the L1 and MLC, and sort the requests in each queue based on the request priority. The "bus out" queue is no longer used after integration with Ramulator.
mem_process_mlc_fill_reqs() and mem_process_l1_fill_reqs() process requests that are filling the MLC and L1, respectively.
ramulator_tick() is called every memory cycle to simulate the workings of the main memory through Ramulator.
mem_process_bus_out_reqs() is basically empty since we no longer use the bus out queue.
mem_process_l1_reqs() and mem_process_mlc_reqs() process requests to the L1 and MLC, respectively.
mem_process_core_fill_reqs() handles filling into the Icache/Dcache, if necessary
3)
For ops that read data from the cache hierarchy, I believe the data has to propagate to the Dache, and we only set the op's done_cycle when it finishes its dcache access (in update_dcache_stage() in src/dcache_stage.c)

I've been meaning to put together a more detailed document that explains how all this works in more detail, but hopefully that'll be enough to get you started.

Thanks,
Ben

from scarab.

Thank you. I feel that disabling the MLC may be problematic, after all, modeling the memory hierarchy well has a significant impact on performance. Feel free to close.

from scarab.

Closing issue as it has been inactive for a while.

from scarab.