Possible bug in handling of write-back requests by disabled cache

38 views
Skip to first unread message

Abhinav Sharma

unread,
Feb 26, 2017, 4:59:48 AM2/26/17
to Macsim Developer
Hi,
While working with the Macsim simulator, I encountered a possible bug in memory.cc . It is related to how write-back requests are handled by disabled caches. The following is my understanding. Can someone please confirm whether it is correct or not?

(The line numbers I mention are according to https://github.com/gthparch/macsim/blob/master/src/memory.cc )

The mechanism in memory.cc:
Write-back requests are sent to a cache through its fill queue (lines 986 or 1412). Upon insertion in fill queue the state to MEM_FILL_NEW (line 707). In process_fill_queue(), the request is handled by the MEM_FILL_NEW case (line: 1176) of the switch statement. If the write-back request hits in the cache, it completes (line: 1263). If the write-back request misses in the cache(line: 1187), it evicts another line, sends a new write-back request to lower level cache for the evicted line (lines 1219-1224), and completes (line 1263). 

Ideally, a disabled cache should forward write-back requests to next lower level. But, I encountered the following.

Possible bug:
If the cache is disabled, then the write-back is assumed to hit in the cache (lines 1179-1185) and no new write-back request is generated. This means that if a cache is disabled, then no write-back requests will be sent to the next lower level. Eg, If L3 is disabled, then no write-back request will be sent to Dram, ever. 
To confirm this, I added an ASSERT(false) after lines 501 and 541 in dram_ctrl.cc (https://github.com/gthparch/macsim/blob/master/src/dram_ctrl.cc). These are the lines where write-back requests are handled in Dram. And indeed, the simulation completed without fail for memory types no_cache (in which all caches are disabled) and l2_coupled_local (in which L3 is disabled). This means that no write-back request went to Dram. And for memory types l3_coupled_network and l3_decoupled_network (where no cache level is disabled) the assertion I added failed, meaning that some write-back request did go to Dram.

It'll be very helpful if anyone can correct me in case I'm missing something. 

Thanks!

Sincerely,
Abhinav A Sharma
Indian Institute of Science
Reply all
Reply to author
Forward
0 new messages