Hi Gjins,
That's right if one L1 has the block in O state (shared and dirty) the other L1 caches will have in S state (shared). Only one cache has the block marked as dirty and it is the one which is responsible for writing back the data. The other L1 caches can evict the block without doing anything - in practice an eviction of a !dirty block will send a CleanEvict to update the snoop filter, or a WritebackClean which will both the snoop filter and will ensure that the block is in the memory below after the eviction. Nikos ________________________________ From: gem5-users <[email protected]> on behalf of Gongjin Sun <[email protected]> Sent: 20 December 2017 00:42:16 To: gem5 users mailing list Subject: Re: [gem5-users] About multiple cache copies and a related comment called "on the same path to memory" Timon and Nikos, thank you so much for these useful and detailed answers. It helps me a lot. Example is always the best explanation :) One more also last question, if the core1's L1 had the block in O state, the state of the block copies in core2's L1, core3's L1 and memory (assume they all have the copies) should be "shared" (also dirty) because only one dirty block copy can be in O state, right? Thanks On Tue, Dec 19, 2017 at 2:41 AM, Nikos Nikoleris <[email protected]<mailto:[email protected]>> wrote: Hi Gjins, In your example, for any of the two cores, the path to the memory includes its private caches and the shared cache and it does not include the private caches of other core. gem5's classic memory model implements a MOESI-like snooping protocol and the cache that has the block with the dirty bit set (block in either M state or O state) is the cache that responds. In this case, the comment clarifies that if the block is additionally marked as shared (a block marked as shared and dirty is in O state) and we need a writable copy, this cache is responding but there are copies of the block in other caches (not in the core's path to the memory) that we need to invalidate. In an example system with 4 cores, each having a private L1 and a shared L2, this means that if core0 needs a writable copy of block A and core1's L1 had the block in O state, core1's L1 will respond to the request, but we need to snoop and invalidate copies that might exist in core2's L1 or core3's L1. The L2 might also have a copy of the block but we don't need to invalidate it. Hope this helps. Nikos On 12/19/17 00:23, Gongjin Sun wrote: Hi All, I noticed that there are some useful comments in the file cache.cc as like these: "// if a cache is responding, and it had the line in Owned // rather than Modified state, we need to invalidate any // copies that are not on the same path to memory " "// we get away with multiple caches (on // the same path to memory) considering // the block writeable as we always enter // the cache hierarchy through a cache, // and first snoop upwards in all other // branches" What is the meaning of "on the same path to memory"? Assume we have two cpus and 3 cache levels. The third level is shared by these two cpus. And packet is in the level 2 (L2) of cpu1 currently. If I understand it correctly, taking the first comment for example, the cache which is responding is L1 of cpu1, the "on the same path to memory" means the path from current L2 of cpu1 to to L3 to memory and the copies which need to be invalidated should be the ones from L1, L2 of cpu2 (not including the copies of L3) . Is my understanding correct? Please correct me and clarify it if not. Thanks in advance! gjins _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
