Sorry, there is a typo: "on onwer exists" should be "no owner exists".
I think more, and still can't understand why 'O' state has a "dirty" set but can't be "writable". This owner has made changes to this line, but is not "writable". That sounds like a contradiction. Or did I miss something? Thanks On Sun, Feb 7, 2016 at 11:03 PM, Gongjin Sun <[email protected]> wrote: > Thank you, Steve. But I'm still a little confused. > > For the "A write hit implies that a cache has an exclusive copy". If a > miss happens at all cache levels, gem5 will bring this data line from > memory to L3 to L2 to L1, level by level. Now this line has three copies > and its state should be shared (clean). Next if a demand write request > arrives at L1, it will hit. So now how can we handle the copies in L2 and > L3? We can invalidate them, or propagate this line from L1 to l2 and l3 and > make its state become shared(dirty) ?? > > Also after I read the comments in CacheBlk::print(), I think gem5's MOESI > looks like not a standard one compared with the MOESI from wikipedia: > https://en.wikipedia.org/wiki/MOESI_protocol > > gem5's MOESI is: > > state writable dirty valid > M 1 1 1 > O 0 1 1 > E 1 0 1 > S 0 0 1 > I 0 0 0 > > For a shared block, according to the explanation of wikipedia, they can be > "dirty" (Here the 'dirty" is with respect to memory), We probably have > several modified copies. But gem5 think they are all clean and can't be > written. Does this mean on onwer exists for shared blocks? . In addition, > why can't a Owned block be "writable"? It's a owner, right? > > I'm so confused. Hope you can help me more. Thank you so much. > > gjins > > > On Sun, Feb 7, 2016 at 10:28 PM, Steve Reinhardt <[email protected]> wrote: > >> Upgrade requests are used on a write to a shared copy, to upgrade that >> copy's state from shared (read-only) to writable. They're generally treated >> as invalidations. >> >> A write hit implies that a cache has an exclusive copy, so it knows that >> there's no need to send invalidations to lower levels. There are some >> relevant comments on the block states in the CacheBlk::print() method >> definition in src/mem/cache/blk.hh. >> >> Steve >> >> >> On Sun, Feb 7, 2016 at 4:04 PM Gongjin Sun <[email protected]> wrote: >> >>> Hi All, >>> >>> Does any know the function of the request called "UpgradeReq"? Under >>> what circumstance will this request be generated? After this request is >>> sent to other cache levels, what will happen to that level? There are so >>> few comments about it. Accord to its use, I guess it is related to write >>> miss. But I'm not sure about the specific functions. >>> >>> In addition, I noticed that when a "write hit" happens in a cache level, >>> this cache will NOT send an invalidate message to its lower levels (closer >>> to mem) to invalidate this line's other copies. Is that correct? (Note: now >>> this cache's upper level (closer to cpu) definitely doesn't contain this >>> line, otherwise there must a write hit in that upper level rather than this >>> cache level.) >>> >>> Thank you in advance >>> >>> Best >>> 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 >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
