Are other cache levels registered like L2 cache levels?

[Yujie-Cui]

Many thanks for the open source code.

1. But I see that multi.l2c_pref defines many prefetchers, such as Bingo, BOP, SPP, MLOP. But multi.l1d_pref only defines IPCP, next_line, stride. Although the papers corresponding to other prefetchers indicate that they are used in L2 or LLC, is it possible to directly move the prefetcher defined by multi.l2c_pref to multi.l1d_pref to use these prefetchers at the L1 level? Or I want to use these prefetchers at LLC level, do I just need to write a multi.llc_pref like multi.l2c_pref?

2. I see that Bingo prefetcher is only defined in multi.l2c_pref. DPC3's open-sourced Bingo runs on the L1D cache, although it uses a large storage overhead. The bingo_l1d_thresh variable is defined in Bingo, which determines whether to prefetch to the L1 level, so does the prefetcher at the L2 level support this function?
   Can Bingo at L2 level prefetch data to L1 cache?

Really Thanks!!!

[rahulbera]

Hi @Yujie-Cui,

Sorry for taking long to reply.

1A. If you directly move multi.l2c_pref to multi.l1d_pref, some prefetchers might work, while other may lose potential. Let's understand with an example. SPP creates a path signature using last four cacheline deltas (meaning, the gap between last two consecutive demand load cacheline addresses) and use the signature to find which delta to prefetch next. Now if you observe cacheline delta at L1-D cache, you will see most of the delta to be zero due to the spatial locality. But this won't be the case if you observe the delta in L2 cache, which will see a memory access stream already filtered by the L1-D cache. This can be one reason why SPP might lose potential if you just put it in L1-D cache without changing any internal logic. I would suggest to go through the logic behind every prefetcher and then make an informed decision on how to move them around the cache hierarchy.

1B. To instantiate prefetchers at LLC level, you can either (1) instantiate them in multi.llc_pref, or (2) play around with the thresholds to change the prefetch fill cache level. Let me explain the last part clearly with an example. Bingo instantiated beside L2 cache fills some of its prefetched lines upto L2, and others only till LLC. Selecting the fill level for a prefetched cacheline is determined by some thresholds. In bingo.ini, you can see there are three thresholds: one for each cache level. The threshold value for L1-D is set to 1.01, meaning Bingo cannot ever fill to L1-D cache (Bingo computes this threshold on a scale of 0 to 1. Check the implementation). Threshold for L2 (and LLC) is set to 0.8 (0.05), meaning any prefetch request with threshold of at least 0.8 (0.05) will be filled into L2 (LLC). Now if you configure these thresholds as follows: bingo_l2c_thresh = 1.01 and bingo_llc_thresh = 0.1, Bingo automatically becomes an LLC prefetcher, which gets trained based on L1-D miss accesses, but fills prefetch requests only to LLC.

2. Maybe DPC-3 Bingo is implemented beside L1-D, but the paper suggests it should be a LLC prefetcher (the paper models a 2 level cache hierarchy, so the second level cache was LLC in that case) due to its size constraints. If you want to create Bingo beside L1-D, you need to modify the code a bit, because the current implementation of Bingo cannot fill in L1-D.