Read Miss Operation at Last Level Cache (LLC)
Hi everyone,
As we already know, a "Read miss" at the last cache level (LLC) means that the desired block in the LLC for reading was not found. Consequently, it is necessary to locate a victim block and copy the desired block from the main memory to the victim block's location in the last cache level.
I want to see the data content of the blocks that were brought to the last level of the cache due to a read miss from the main memory. However, I am unsure where the Read Miss operation is implemented. Based on my research, it appears that the function:
CacheBlk* BaseCache::handleFill(PacketPtr pkt, CacheBlk *blk, PacketList &writebacks, bool allocate)
maybe helpful in this regard.
I would greatly appreciate any suggestions or guidance on how to effectively validate my findings. For your information, I am utilizing a classic cache configuration and an O3 CPU type.
Thank you for your attention to this matter, and I eagerly look forward to your guidance.
Sincerely,
Zahra Moein
On 11/30/2023 2:07 PM, zahra moein via gem5-users wrote:
Hi everyone,
As we already know, a "Read miss" at the last cache level (LLC) means that the desired block in the LLC for reading was
not found. Consequently, it is necessary to locate a victim block and copy the desired block from the main memory to the
victim block's location in the last cache level.
I want to see the data content of the blocks that were brought to the last level of the cache due to a read miss from
the main memory. However, I am unsure where the Read Miss operation is implemented. Based on my research, it appears
that the function:
CacheBlk* BaseCache::handleFill(PacketPtr pkt, CacheBlk *blk, PacketList &writebacks, bool allocate)
maybe helpful in this regard.
I would greatly appreciate any suggestions or guidance on how to effectively validate my findings. For your information,
I am utilizing a classic cache configuration and an O3 CPU type.
Thank you for your attention to this matter, and I eagerly look forward to your guidance.
If you're running a timing model, the packet will arrive with
a RecvTimingResp call. The code for that function will look
at the nature of the response and possibly load data into a
cache block. That's where I would look.
Best wishes - EM
Thank you for your response.
I would like to seek further clarification regarding the parameter RecvTimingResp:
void BaseCache::recvTimingResp(PacketPtr pkt)
Could you please confirm if this parameter represents a packet that is received from memory? If it does, I would appreciate your guidance on how to determine whether this packet is a response to a read miss request in the last-level cache.
Thank you for your valuable assistance.
Best regards,
Zahra Moein
On 12/1/2023 6:24 PM, zahra moein via gem5-users wrote:
Thank you for your response.
I would like to seek further clarification regarding the parameter RecvTimingResp:
void BaseCache::recvTimingResp(PacketPtr pkt)
Could you please confirm if this parameter represents a packet that is received from memory? If it does, I would
appreciate your guidance on how to determine whether this packet is a response to a read miss request in the last-level
cache.
Thank you for your valuable assistance.
It's a packet received from whatever the cache is connected to. If it's the
last level cache, then it should come from the memory bus, which would have
gotten it from memory. But you need to analyze what sort of packet it is, and
the nature of the request that resulted in the packet, etc. You should at
least get a sense of the control flow of that function and perhaps of some of
the significant functions it calls.
If the data are headed for this cache, then there will be some place where
they get loaded into a cache block.
I'm not sure you can say with 100% certainty it has to do with a read miss,
though if you look for where read misses generate requests, that may be
helpful. One possibly confounding case is packet arriving because of prefetch
- but I think they should be marked as such.
Btw, another case is when another cache responds, but from the viewpoint of
this cache it will still be a recvTimingResp (at the memory bus, a
recvTimingSnoopResp will be involved).
My intention was to point you where to start understanding the code, well
enough at least, not to indicate the specific code location. (My notion is
that you'll be better off if you study it some and learn more about how it
works (not every detail, since there's a lot of complexity there!), as opposed
to being directed to specific line(s) of code.) Another clue would be where
statistics counters get updated :-) .
It's conceivable that it will be easier to find the data coming from memory
due to read misses by looking at packets coming to the memory bus from the
memory controller(s). (I assume you're not interested in data arriving from
I/O devices.)
If you end up really stuck, I may be able to find time to take a look.
HTH -- EM
Hello,
Thank you very much for your response. I appreciate your assistance, and I made an effort to understand the code, which provided me with a better understanding.
However, I couldn't determine the exact origin of the packet sent by sendTimingResp() for it to be received by recvTimingResp().
I defined a counter and counted the number of times handleFill() was called in the last-level cache. This count was equal to system.l2.overallMshrMisses::total and system.mem_ctrls.dram.numReads::total.
The last-level cache is L2, and the prefetcher is disabled.
Based on this, can I conclude that whenever handleFill() is used in the last-level cache, a block is evicted from the last-level cache, and a clean block is brought from the main memory to the last-level cache?
Thank you,
Zahra Moein
On 12/8/2023 1:31 AM, zahra moein via gem5-users wrote:
Hello,
Thank you very much for your response. I appreciate your assistance, and I made an effort to understand the code, which
provided me with a better understanding.
However, I couldn't determine the exact origin of the packet sent by sendTimingResp() for it to be received by
recvTimingResp().
I defined a counter and counted the number of times handleFill() was called in the last-level cache. This count was
equal to system.l2.overallMshrMisses::total and system.mem_ctrls.dram.numReads::total.
The last-level cache is L2, and the prefetcher is disabled.
Based on this, can I conclude that whenever handleFill() is used in the last-level cache, a block is evicted from the
last-level cache, and a clean block is brought from the main memory to the last-level cache?
I think your conclusion may be too strong because a block can be moved
from the IO cache (for example) to the last level cache. A block brought
from memory is by definition clean, so that part holds. I think violation of
your assumption would be rare, and perhaps in some systems it would always
hold.
HTH.
Eliot Moss