> On May 23, 2013, 8:10 p.m., Ali Saidi wrote: > > Thanks for this Erik, > > > > My only issue with the way this is handled, is if the CPU runs out of cache > > ports, I'm pretty sure it will squash the entire pipeline and start > > re-fetching, which doesn't seem right to me. Anyone else? > > > > Thanks, > > Ali > > > > Erik Tomusk wrote: > Looking at a trace, I think you're right--when the cache blocks, > DefaultIEW<Impl>::executeInsts() calls squashDueToMemBlocked(). I don't quite > understand why instructions should get squashed on a blocked cache, but I > think it makes sense to do the same thing for both a blocked cache and when > the ports limit is reached.
I haven't looked at the code in detail, but it seems like there are two different situations here: 1. When the LSQ knows ahead of time that it can't send any (more) accesses to the dcache 2. When the LSQ finds out after sending an access to the dcache that the access won't succeed In case #1, there's no reason for any squashing, you just don't send the access to the cache in the first place. This should apply both to the port limits (if you have 2 ports, just send 2 accesses, don't try to send a 3rd) and to the case where the cache is already blocked at the beginning of a cycle and you're waiting for a retry. Case #2 is the only one where you have a squash, I think, and I believe the only scenario where it applies is when you first find out that the cache is blocked... since you find out by trying to send an access and getting a 'false' response. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1872/#review4350 ----------------------------------------------------------- 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
