To Include or Not to Include Natalie Enright

To Include or Not to Include? Natalie Enright Dana Vantrease

Motivation n CMP technology affects coherence protocols differently than previously studied MP systems n n Industry Examples n n n New shared on-chip resources (e. g. L 2) Low latency between on-chip caches Need for scalability in design IBM Power 4 – Inclusion Piranha – Exclusion Our goal: Determine at which point, each inclusion protocol (strict inclusion, non-inclusion and exclusion) is the best choice for CMP performance.

SMP vs CMP Opportunities L 1 L 1 VS L 2 L 1 VS L 2 L 2 L 1

Multilevel Inclusion n Protocol given to us with the simulator n n L 1 has Modified, Shared and Invalid States L 2 has Modified, Owned, Shared, and Invalid States When an L 2 line is replaced, any copies present on the chip must be invalidated (the sharers are given in the directory entry) In a single processor chip, there are only 2 caches (Instruction and Data) connected to a single L 2 cache n Chip multiprocessors introduce an additional 2 level 1 caches per processor which could make this forced inclusion harmful.

Non-Inclusion n Protocol courtesy of Mike L 1 now has owned and exclusion states Complexity of the on chip directory has increased significantly n n n States added to indicate local level 1 sharers or a local level 1 owner. L 1 directory state also needs to be visible for external requests from other chips Increase effective on-chip cache storage

Directory Exclusion n No replication of Data between a single L 1 and the L 2 n n n L 2 Acts as Large Victim Cache Utilizes cache space, lowering required off-chip bandwidth L 2 is centralized coherency point (tag lookup) L 1 States: M, E, I, SC, SM L 2 States: M, E, I No ownership – simply request 1 st Sharer in Tag Lookup for Data Request

Directory Exclusion L 1 L 1 Tags L 1 Tags L 2 L 1

Tag Lookup Cache n n n Aids in off-chip coherency and directing onchip requests Associativity = L 1 associativity * # L 1 s # Sets = #Sets in a single L 1 # Data Entries = # L 1 s Data Entry = The L 1 corresponding to the Data Entry has the data or not (1/0). Scalability?

Methodology n n Vary the L 1 cache size to find the design point at which an inclusive protocol hurts performance. As the number of cores increases, so does the aggregate L 1 cache size

Simulation Configuration n n 4 processors per chip and 1 chip 2 MB of L 2 cache n n Small but wanted to see the effect of changing the ratio of L 1 size to L 2 size. 16 processors per chip as future work Only simulated one chip to isolate the effects of intra-chip coherence from inter-chip coherence Future work: see how extending the life of a block on chip through non-inclusion or exclusion affects other chips.

Results Inclusion vs. Non-Inclusion

Results (cont. ) Inclusion vs. Pseudo-Exclusion

Conclusion/Future Work n An inclusive protocol is less complex n n Non-Inclusion performs consistently better than inclusion n n Esp. considering inter-chip communication Additional complexity only warranted after the total L 1 cache size is greater than 25% of the L 2 cache size. Longer runs and more benchmarks would provide more conclusive evidence

Future Work n Ongoing: Get working exclusion protocol in Ruby tester and Simics. n n Run comparable tests to those run for Noninclusion n n Current Status: Currently runs 500 memory transactions in the Ruby tester. Analyze benefits of exclusion over inclusion. Expand to 16 cores and study scalability issues.