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 <nikos.nikole...@arm.com> 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 >> gem5-users@gem5.org >> 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 > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
