----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1872/#review4397 -----------------------------------------------------------
Just a random thought. This patch is a good step in the right direction, but why don't we simply use a vector master port for the D side and cycle through them round robin (or pick which ever is free)? src/cpu/o3/O3CPU.py <http://reviews.gem5.org/r/1872/#comment4123> Data ports? src/cpu/o3/lsq_unit.hh <http://reviews.gem5.org/r/1872/#comment4124> const unsigned int? src/cpu/o3/lsq_unit.hh <http://reviews.gem5.org/r/1872/#comment4125> == rather than >=? src/cpu/o3/lsq_unit.hh <http://reviews.gem5.org/r/1872/#comment4126> When is this ever decremented? How do we link a decrement of this with getting things going again (or do we simply keep on trying and fail until the number is reduced)? src/cpu/o3/lsq_unit_impl.hh <http://reviews.gem5.org/r/1872/#comment4127> \n at the end? src/cpu/o3/lsq_unit_impl.hh <http://reviews.gem5.org/r/1872/#comment4122> Is the port not also "used" on a blocked request that is waiting for a retry? - Andreas Hansson On June 5, 2013, 6:13 a.m., Erik Tomusk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1872/ > ----------------------------------------------------------- > > (Updated June 5, 2013, 6:13 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9722:7026fe0f45b4 > --------------------------- > O3CPU: Revive cachePorts per-cycle dcache access limit > This is a stop-gap patch to place a limit on the number of dcache requests the > LSQUnit sends each cycle. Currently, the LSQUnit will send any number of > requests, leading to unrealistic dcache usage. Note that there is an LSQUnit > for each hardware thread, so the cachePorts limit is enforced on a per-thread > basis. > > What this patch does NOT do: > *Limit icache accesses > *Limit dcache accesses from sources other than the LSQUnit (e.g. accesses from > L2) > > I'd like to refactor the second half of LSQUnit<Impl>::read(), as it's very > messy. It would be helpful to get feedback on whether what it does is > functionally correct before I do. > > It would also be helpful if someone who understands split memory accesses > could check if that bit of code is correct, since I don't know how to test > it. > > > Diffs > ----- > > src/cpu/o3/O3CPU.py eb075b2b925a > src/cpu/o3/iew_impl.hh eb075b2b925a > src/cpu/o3/lsq_unit.hh eb075b2b925a > src/cpu/o3/lsq_unit_impl.hh eb075b2b925a > > Diff: http://reviews.gem5.org/r/1872/diff/ > > > Testing > ------- > > When cachePorts is set to 200 (the old value), this patch passes > ARM/tests/fast/long with the exception that the regression complains about > the new statistic. > > > Thanks, > > Erik Tomusk > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
