Thanks all for the comments.
So, briefly, the problem atm is that the L1 cache will service any
number of requests per cycle whereas in the real world, physical
read/write port limits mean it can only service ~2. Amin's patch puts
bottlenecks in all the right places, but there are questions about how
it's implemented. I too don't have time to adopt Amin's patch and get it
committed.
For the I-cache, ports shouldn't be a big issue, because from what I can
tell, fetch only accesses one block per thread per cycle.
For the D-cache, making the cachePorts functionality work again would
throttle the number of requests from the core. If I understand
correctly, a cache miss is still physically a cache access, so what
happens in the MSHR shouldn't affect how many requests the core sends
per cycle. The shortcoming of the cachePorts limit is that it ignores
accesses to the L1D that don't originate in the core (e.g. data from L2
to L1D).
So it looks like cachePorts gives 80% of the desired behavior with 20%
of the effort. Given that there's nothing better on the horizon, I can
try to get cachePorts to work again and make a patch.
Any thoughts?
-Erik
On 11/05/13 15:14, Ali Saidi wrote:
On May 10, 2013, at 11:26 AM, Amin Farmahini <amin...@gmail.com
<mailto:amin...@gmail.com>> wrote:
On Fri, May 10, 2013 at 10:10 AM, Erik Tomusk <e.tom...@sms.ed.ac.uk
<mailto:e.tom...@sms.ed.ac.uk>> wrote:
*It shouldn't be too difficult to re-introduce the access limit
set by cachePorts. However, this change would be undone and
superseded by patch #1422 on the reviewboard if it ever gets
committed. Is re-introducing the cachePorts limit worthwhile?
The cachePorts thing is very simplistic. The patch, on the other
hand, does not conform with gem5 rules. I do not think this patch
gets ever committed because I don't have time to fix it. You may want
to take a look at and get some ideas.
I would like to see something like Amin's patch committed, however I
too haven't had enough time to clean up his patch a little bit and I'm
not completely sure if it's the best way to go about things, but I'm
happy for an OK way that fixes a problem.
Thanks,
Ali
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users