I want to clarify what I believe is an oversight: With respect to functional reads, it's not really correct to just "return the first valid value found in some ruby structure."
A relaxed protocol (e.g. the quickrelease paper by Blake Hechtman et al.) might allow two versions of a cache block to exist in different caches, such that different parts of the cache line are being read by different threads For example, thread 1 on core 1 might be writing the first 32 bytes of a 64-byte cache line while thread 2 on core 2 is writing the second 32 bytes. There is no race here because the different versions of the cache line are "merged" as appropriate. A more complete solution would need to track cache blocks at a byte/word granularity and assemble the functional read's return value from one or more cache blocks that it finds in the ruby system. Thanks, Marc On Mon, Oct 27, 2014 at 2:37 PM, Nilay Vaish via gem5-dev <[email protected] > wrote: > On Mon, 27 Oct 2014, Beckmann, Brad wrote: > > I agree with Joel that this has been an interesting discussion. While >> there are questions about how these situations can occur and what is the >> best way to fix them, there doesn't seem to be anyone resisting the fact >> that this patch should be checked in, correct? I think it is very >> important that we not require protocols to always provide completely >> functional memory. >> > > > I still need to look into how checkpoints will work. With the current > code, the existing checkpoints will not work at all. > > -- > Nilay > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
