Should these be dynamic based on the number of sets? It seems that this algorithm breaks when the number of sets is less than 2^10. I know you had stated that there isn't literature about RRIP in anything other than the LLC, but given ChampSim's place as a research tool, it shouldn't surprise us if someone tries to put it in the L1.

In general, increasing the percentage of leader sets (beyond 1 in 32 per policy) can cause performance degradation since the leader sets are statically assigned a policy and the leader sets for the unselected policy will always do worse. This is might be further exacerbated in small caches which don't have that many sets to begin with. The above trade-off would need to be better explored to determine what a reasonable amount of sampling would be for smaller caches.

That said, from the small set of SPEC workloads that I've tested, a 64-set L1D seems largely insensitive to the replacement policy (IPC is within +- 0.01).

I don't mean to debate whether or not it's a good idea to put this policy in the L1. What I'm saying is that someone is definitely going to try it, and these hard-coded magic numbers are going to unfairly penalize them for doing that. This user won't know that they need to go in and change 0x1F to 0x3 or some other good value. This isn't a microarchitectural point, it's a defense-against-intrepid-users point.

Gotcha. What I was trying to say that it's not clear what a reasonable default would be for a small cache like the L1. If we don't want to leave it up to the user, I suppose we could arbitrarily assign some defaults:

• 1024+ sets => 1 in 32 per policy (64 total leader sets at 1024)
• 256 to 1024 sets => 1 in 16 per policy (32 total leader sets at 256)
• 64 to 256 sets => 1 in 8 per policy (16 total leader sets at 64)
• 8 to 64 sets => 1 in 4 per policy (4 total leader sets at 8)
• < 8 sets => Assertion Failure?

To make it somewhat more transparent (and less magic-number-y), I could extract out the leader set detection:

bool is_leader_set(bool brrip, uint64_t set) {
    uint64_t mask = SET_SAMPLE_RATE - 1;
    uint64_t shift = champsim::lg2(SET_SAMPLE_RATE);
    if(brrip)
        return (set & mask) == ~((set >> shift) & mask);
    return (set & mask) == ((set >> shift) & mask);
}

where SET_SAMPLE_RATE is a power of two such as 32.

That seems like a reasonable set of arbitrary defaults. And, refactoring out is_leader_set() feels like a good idea. I might do something more like

enum class leader_class {
    follower, brrip_leader, srrip_leader
};
[[nodiscard]] constexpr leader_class is_leader_set(long set) {
    auto mask = SET_SAMPLE_RATE - 1;
    auto shift = champsim::lg2(SET_SAMPLE_RATE);
    auto low_slice = set & mask;
    auto high_slice = (set >> shift) & mask;
    if (high_slice == ~low_slice) {
        return leader_class::brrip_leader;
    } else if (high_slice == low_slice) {
        return leader_class::srrip_leader;
    }
    return leader_class::follower;
}

This is a bit more explicit about how the function tells you if the set is a leader and, if so, which kind.

I think this is a good idea. We should put it in champsim::modules::replacement, rather than CACHE. The latter is bloated enough already. A naming consideration: the word "index" seems overloaded here. Should we consider a name like get_set_sample_category()?

Hi,
I have a doubt in chosing the total sampler sets
With this set_sampling_rate we set the default sampling rate based on the cache level that uses this replacement policy. But will the code also give provision to set the total number of sampled sets??
Just like if i want to track only k sets then which parameter to change? The code only has provision to fix the rate but not the number of such sets. lets say for 1 in 32 policy if we get 32 leader sets per policy, if i need only first 16 leader sets out of that then what should be done?? In the code i could see if sampling_rate is fixed then no of sampled sets gets fixed. If I wanted to choose a few out of that then what needs to be done?? Could you pls help me with this query.

Are you asking for a parameter that controls the number of sampled sets? Currently, the only way to do this is to modify the code (which, given that this is in a user module, seems reasonable to me). If you want a parameter in the configuration file, I have a call for contributions open in #422. Would you consider contributing to that?

1)I don't mean to having parameter in config file, but may be i thought the parameter could be declared and used in replacement policy file itself.
2) What exactly is the user module means?
3)I am not really sure how to develop logic to set the number of sampled sets and use it. So couldn't be able to contribute at this point of time.

I suggest you read the documentation. I think that if you want the things you're asking for, you'll have to get your hands dirty and modify the source code.