O3CPU: Revive cachePorts per-cycle dcache access limit
Review Request #1872 - Created May 16, 2013 and updated - Latest diff uploaded
| Information | |
|---|---|
| Erik Tomusk | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
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.
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.
