What do the different access_type enum values defined in inc/channel.h represent?

[Setu-Gupta]

The access type is passed to the replacement policy via the find_victim and update_replacement_stats callbacks. I wanted to know exactly what do all the different enum values represent. From what I can understand, these enum values represent the following type of cache accesses:

• LOAD: This represents a read memory request from the core side
• RFO: This represents a read memory request from sibling caches at the same cache level for coherency reasons
• PREFETCH: This represents a prefetch request from the core side
• WRITE: This represents a write memory request from the core side

What does the TRANSLATION enum value represent?

Moreover, while implementing replacement policies, how can I distinguish between the memory requests from the core side and the cache fills from the RAM side? I assume that this line in the LRU implementation checks for this. However, what I don't understand is that why a cache fill is not a WRITE access type. Can someone please explain this to me?

[ngober]

The access types all refer to the type of request, not the type of action being taken. So, WRITE refers to either a store (from the core), or a writeback (from a cache). TRANSLATION requests originate from a PTW.

When update_replacement_state() is called, it is always called with the access type from the request. It is true that a load may cause a fill (in the case of a cache miss), but this is not then called a WRITE. It is still called a LOAD.

[Setu-Gupta]

Thanks for the clarification!

[Setu-Gupta]

Just to be clear, in case of a cache miss, I would then see two requests. The first one will be from the core side for the access, and one will be from the RAM side for fills. Since I cannot distinguish between these two request on the basis of access_type, how can distinguish between the two? I assume that hit would be set to false in both cases as both these requests were triggered by a cache miss.

[ngober]

Yea, if we examine src/cache.cc, we see that there are two calls to update_replacement_state(): one in CACHE::try_hit() with hit=1, and the other in CACHE::handle_fill() with hit=0. So misses do not become visible to the replacement policy until they are filled. This is retained because it was an older behavior of ChampSim. The interface should probably be modified to match the prefetcher: having a cache_operate() function called after the tag check whether it hits or misses, and having a cache_fill() function that is called when a miss is filled. Or, perhaps, we should just make update_replacement_state() the operate function and rely on find_victim() to act as the fill hook.