> On June 6, 2013, 10:10 a.m., Andreas Hansson wrote: > > 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)?
Wouldn't that mean that for every tick we'd have to keep track of not just how many ports have been used, but also which ones? And we might have to include some code next to every dcache access to do a search for unused ports. > On June 6, 2013, 10:10 a.m., Andreas Hansson wrote: > > src/cpu/o3/O3CPU.py, line 55 > > <http://reviews.gem5.org/r/1872/diff/2/?file=35776#file35776line55> > > > > Data ports? I'm not sure either is better. "Cache ports" gets used in the literature, but also means something different in the gem5 context. > On June 6, 2013, 10:10 a.m., Andreas Hansson wrote: > > src/cpu/o3/lsq_unit.hh, line 839 > > <http://reviews.gem5.org/r/1872/diff/2/?file=35778#file35778line839> > > > > 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)? It's reset in tick(). > On June 6, 2013, 10:10 a.m., Andreas Hansson wrote: > > src/cpu/o3/lsq_unit_impl.hh, line 1205 > > <http://reviews.gem5.org/r/1872/diff/2/?file=35779#file35779line1205> > > > > Is the port not also "used" on a blocked request that is waiting for a > > retry? Practically, I don't think it matters--if the cache is blocked in a given cycle, nothing's going in or out regardless of the number of free ports. In terms of real hardware, I think it depends on what caused the cache to block. This patch tries to model the fact that there are only so many physical wires going into each memory cell, and once they've carried some data in a cycle, there's no more time to carry more. If the cache is blocked because of some buffering somewhere, then I guess the answer is no. - Erik ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1872/#review4397 ----------------------------------------------------------- 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
