----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3347/#review8056 -----------------------------------------------------------
Seems fine, though: 1. It's weird that we're passing in a 1 to mean "no reserve entries" and "p->mshrs + 1" to mean "as may reserve entries as MSHRs". I realize that's an issue with the semantics of the parameter, and outside the scope of this patch, but if we're ever going to clean that up now would be a good time. 2. it would be nice to have a forward pointer comment by the initializers so people know there's a more detailed comment below - Steve Reinhardt On Feb. 24, 2016, 1:28 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3347/ > ----------------------------------------------------------- > > (Updated Feb. 24, 2016, 1:28 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11353:b25ca3acdefb > --------------------------- > mem: Adjust cache queue reserve to more conservative values > > The cache queue reserve is there as an overflow to give us enough > headroom based on when we block the cache, and how many transactions > we may already have accepted before actually blocking. The previous > values were probably chosen to be "big enough", when we actually know > that we check the MSHRs after every single allocation, and for the > write buffers we know that we implicitly may need one entry for every > outstanding MSHR. > > > Diffs > ----- > > src/mem/cache/base.cc ef6e57ac0d70 > > Diff: http://reviews.gem5.org/r/3347/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
