Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefetcher coverage, accuracy calculation and throttling mechanism that requires correct pfUseful metric is incorrect for classic cache #785

Open
AbhishekUoR opened this issue Jan 18, 2024 · 3 comments
Labels

Comments

@AbhishekUoR
Copy link

Describe the bug

  1. The pfUseful statistic is only accounted on ppHit/ppMiss at recvTimingReq(PacketPtr pkt) function call. When a cache is an exclusive from its upstream cache, it invalidates the block at BaseCache::maintainClusivity(bool from_cache, CacheBlk *blk), which is called inside BaseCache::access(PacketPtr pkt, CacheBlk *&blk, Cycles &lat, PacketList &writebacks) that deletes the block before it can be accounted as useful prefetch block.

  2. The demandMshrMisses does not account for the demand requests that have arrived at the cache and are missed. On miss, the MSHR is looked up, but if an MSHR packet is created due to prefetcher (late prefetch), the demandMshrMisses counter does not account for it.

  3. The clearPrefetched() is not called on blocks for which a request is generated to go to the downstream cache due to not having the correct coherence state. This leads to additional pfUseful counts on WriteReqs (L1D cache).

Affects version
It was found in Version 23.0.0.1

gem5 Modifications

  1. pfUseful: I have included new counters inside the incHitCount function call, but I can include ppHit in it as this will notify the prefetcher on Hit and perform training for a few algorithms. Similarly, ppMiss can be included on incMissCount for prefetched load blocks that need writable blocks and account for pfUsefulButMiss.

  2. demandMshrMisses: I have added a check at void BaseCache::handleTimingReqMiss(PacketPtr pkt, MSHR *mshr, CacheBlk *blk, Tick forward_time, Tick request_time) to check the mshr target source and account for missed out demandMshrMisses due to late prefetch.

  3. clearPrefetched(): I am clearing the flag at void Cache::serviceMSHRTargets(MSHR *mshr, const PacketPtr pkt, CacheBlk *blk) under this condition "if (blk && blk->isValid() && (!mshr->isForward || !pkt->hasData())) {.."

To Reproduce

  1. Compile gem5 with the command: scons build/ARM/gem5.opt
  2. Execute the simulation with: ./build/ARM/gem5.opt configs/deprecated/example/se.py -c (array_access_binary_arm) --cpu-type=DerivO3CPU --caches --l1d-hwp-type TaggedPrefetcher --l2-hwp-type TaggedPrefetcher

If possible, please include the Python configuration script used and state clearly any parameters passed.
Changed clusivity in src/mem/cache/Cache.py to mostly_excl for L2 cache

Host Operating System
Rede Hat

Host ISA
X86

@AbhishekUoR AbhishekUoR changed the title Prefetcher coverage and accuracy calculation is incorrect for classic cache Prefetcher coverage, accuracy calculation and throttling mechanism that requires correct pfUseful metric is incorrect for classic cache Jan 19, 2024
@ivanaamit
Copy link
Contributor

@AbhishekUoR, do you have a fix for this issue? If yes, please feel free to contribute. Thank you.

@ivanaamit
Copy link
Contributor

Hi @AbhishekUoR, following up on this. Do you have a fix for this issue? Thanks.

@AbhishekUoR
Copy link
Author

Hi @AbhishekUoR, following up on this. Do you have a fix for this issue? Thanks.

Hello, I have some changes, but they're more like temporary fixes. This month, I'm occupied with my work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants