> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote: > > src/mem/cache/cache.cc, line 1097 > > <http://reviews.gem5.org/r/3156/diff/2/?file=51182#file51182line1097> > > > > I'm confused as to why the writeback of tempBlock is treated > > differently from all the other writebacks. > > Andreas Hansson wrote: > I am not sure I understand your question. Is it "why don't we just stick > it on the list of writebacks"? > > Steve Reinhardt wrote: > yes, exactly > > Andreas Hansson wrote: > It is all rather unfortunate, and largely due to how the atomic CPU calls > the I side and D side in the same tick, and does not let anything get in > between, unless we tamper with the event priorities. Ultimately the temp > block does end up in the writeback list, and we call the "normal" > doAtomicWritebacks.
I have added a more elaborate comment in the code now to clarify that the writeback has to happen _after_ the call to recvAtomic is completed, since we end up confusing the snoop filter otherwhise (we need to let a fill complete before we evict the block again). - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3156/#review7473 ----------------------------------------------------------- On Nov. 4, 2015, 12:52 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3156/ > ----------------------------------------------------------- > > (Updated Nov. 4, 2015, 12:52 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11195:8bf51d20200d > --------------------------- > mem: Add cache clusivity > > This patch adds a parameter to control the cache clusivity, that is if > the cache is mostly inclusive or exclusive. At the moment there is no > intention to support strict policies, and thus the options are: 1) > mostly inclusive, or 2) mostly exclusive. > > The choice of policy guides the behaviuor on a cache fill, and a new > helper function, allocOnFill, is created to encapsulate the decision > making process. For the timing mode, the decision is annotated on the > MSHR on sending out the downstream packet, and in atomic we directly > pass the decision to handleFill. We (ab)use the tempBlock in cases > where we are not allocating on fill, leaving the rest of the cache > unaffected. Simple and effective. > > This patch also makes it more explicit that multiple caches are > allowed to consider a block writable (this is the case > also before this patch). That is, for a mostly inclusive cache, > multiple caches upstream may also consider the block exclusive. The > caches considering the block writable/exclusive all appear along the > same path to memory, and from a coherency protocol point of view it > works due to the fact that we always snoop upwards in zero time before > querying any downstream cache. > > Note that this patch does not introduce clean writebacks. Thus, for > clean lines we are essentially removing a cache level if it is made > mostly exclusive. For example, lines from the read-only L1 instruction > cache or table-walker cache are always clean, and simply get dropped > rather than being passed to the L2. If the L2 is mostly exclusive and > does not allocate on fill it will thus never hold the line. A follow > on patch adds the clean writebacks. > > The patch changes the L2 of the O3_ARM_v7a CPU configuration to be > mostly exclusive (and stats are affected accordingly). > > > Diffs > ----- > > configs/common/O3_ARM_v7a.py 2d1d51615e0e > src/mem/cache/Cache.py 2d1d51615e0e > src/mem/cache/base.hh 2d1d51615e0e > src/mem/cache/cache.hh 2d1d51615e0e > src/mem/cache/cache.cc 2d1d51615e0e > src/mem/cache/mshr.hh 2d1d51615e0e > src/mem/cache/mshr.cc 2d1d51615e0e > src/mem/cache/mshr_queue.hh 2d1d51615e0e > src/mem/cache/mshr_queue.cc 2d1d51615e0e > > Diff: http://reviews.gem5.org/r/3156/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
