The O state normally is not a writable state (that's what differentiates it from M). The description in the wikipedia article is not very good; I suggest reading about MOESI from a textbook or some other source you may have access to.
The gem5 protocol is a little unusual in how it handles states across different levels in a multi-level hierarchy, but that's covered in the comment I pointed you at previously. Steve On Sun, Feb 7, 2016 at 11:14 PM Gongjin Sun <[email protected]> wrote: > 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
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
