Why are the meta read states necessary for MSHRS?

[Tom George]

We arrive at the s_meta_read state once we already have a req in the mshr (which comes from handle_pri_req). Since the point of the meta read states is to see if the meta is dirty, why do we need to do that if we already set req_needs_wb in handle_pri_req (so we should already know if we need to do writeback)?

[Jerry Zhao]

My memory is fuzzy here, but from reading the RTL I believe it is to avoid a race condition with probes.
In between when the req arrives at the MSHR, and when it is ready to do the eviction, the replaced line could have been already evicted due to a probe.

This is actually not that uncommon. For instance, with an inclusive next level cache, a L1 miss that also misses in the L2 could cause the L2 to evict the same line that the L1 has selected for eviction. In this case, the probe must be allowed to proceed to avoid deadlock.

-Jerry

On Wed, Jul 31, 2024 at 10:27 AM Tom George <tommat...@gmail.com> wrote:

We arrive at the s_meta_read state once we already have a req in the mshr (which comes from handle_pri_req). Since the point of the meta read states is to see if the meta is dirty, why do we need to do that if we already set req_needs_wb in handle_pri_req (so we should already know if we need to do writeback)?

--
You received this message because you are subscribed to the Google Groups "riscv-boom" group.
To unsubscribe from this group and stop receiving emails from it, send an email to riscv-boom+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/riscv-boom/3fde9390-e0c2-43eb-b73e-1cc034b05ff8n%40googlegroups.com.

[Jerry Zhao]

I should add that the re-read of the tags, while wasteful in most cases, is at least not on the critical path of load misses, which the MSHR is designed to minimize.

A more elegant design could have the probes check and update the MSHRs.

-Jerry