Hello, may I ask which piece of code implements the third step?

[szuhzw]

@rahulbera

[rahulbera]

Hi @szuhzw, the code in the dram_controller.cc handles this part. When a LLC load miss arrives at the memory controller (the add_rq function at dram_controller.cc:437), it checks for duplicates in the DRAM RQ (dram_controller.cc:529). If a duplicate is found (meaning a transaction to the same cacheline address is already sent to the DRAM, line 532), the incoming request would get merged to the existing RQ entry. This is very similar to an MSHR's functionality inside caches. If the existing request in the RQ is of type DDRP (direct DRAM prefetch, a code name we used to designate requests generated by Hermes, line 541), and the incoming request is an LLC miss (line 543), the incoming request gets merged to the existing RQ entry (line 548-556).

Hope this clarifies it.

[szuhzw]

Thank you!

[szuhzw]

Hello, may I ask which part of the code implements the description shown in the figure?

@rahulbera

[rahulbera]

Hi @szuhzw, check the process() function inside dram_controller.cc. When a DRAM RQ entry gets processed, the controller checks the fill level. If the fill level is lower than FILL_DDRP (dram_controller.cc:359), which means that the request needs to be filled to the cache hierarchy, the controller sends the data back to the cache hierarchy (line 361). Otherwise, if the DDRP buffer is enabled (which is not in our case), there's a possibility to buffer this data that just returned from the DRAM (line 367-382). If the buffer is not enabled, the data simply gets wasted (the else block at line 384). Essentially, we modelled the DRAM transaction for such wasted requests, but the data does not get pushed into the cache hierarchy.

Hope this helps.

[szuhzw]

Thank you!

[szuhzw]

Hello, may I ask what the three variables in the figure mean?

@rahulbera