----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3156/#review7441 -----------------------------------------------------------
I am mostly ok. I think I'll read it again sometime this week. src/mem/cache/cache.hh (line 238) <http://reviews.gem5.org/r/3156/#comment6281> I would prefer WritebackTempBlock and WritebackTempBlockEvent. I think 'do' is needless and requires more characters. src/mem/cache/cache.cc (lines 1681 - 1683) <http://reviews.gem5.org/r/3156/#comment6283> nullptr - Nilay Vaish On Nov. 2, 2015, 10:44 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3156/ > ----------------------------------------------------------- > > (Updated Nov. 2, 2015, 10:44 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11190:df17c209342a > --------------------------- > 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 4daf60db14d7 > src/mem/cache/Cache.py 4daf60db14d7 > src/mem/cache/cache.hh 4daf60db14d7 > src/mem/cache/cache.cc 4daf60db14d7 > src/mem/cache/mshr.hh 4daf60db14d7 > src/mem/cache/mshr.cc 4daf60db14d7 > > 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
