Great, thanks again, Nikos. The code of classic cache model is becoming better and better. I believe these code (and related comments) will help the users learn more about the cache architecture.
Best gjins On Wed, Dec 20, 2017 at 1:03 AM, Nikos Nikoleris <[email protected]> wrote: > 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]> > 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] > 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 > > > 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
