Hi gjins, To the best of my knowledge, your reasoning is correct. If a packet goes from cpu to the memory, it passes the local caches and then the shared caches on its way to memory. Local caches from other cpu's are not passed, thus meaning they are not on the path to memory. It could be interesting to look a little further into the MOESI cache coherence protocol, since that is the coherence protocol used by default by the classic cache system in gem5.
Regards, Timon On Tue, Dec 19, 2017 at 1:23 AM, Gongjin Sun <[email protected]> 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
