----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1872/#review4395 -----------------------------------------------------------
src/cpu/o3/lsq_unit.hh <http://reviews.gem5.org/r/1872/#comment4120> This implies that both halves of an unaligned access have to go on the same cycle... is my interpretation accurate, and if so, does this restriction make sense? And if it does, why don't we check up front that we have two free ports before sending the first half? Offhand, I don't see any reason for this restriction. I can't find anything in the official docs, but some googling indicates that unaligned memory accesses are not guaranteed to be atomic, and sending both halves in the same cycle doesn't guarantee atomicity anyway (maybe if both halves are in the same cache line, but definitely not otherwise). - Steve Reinhardt 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
