Hi All,
I've been looking at L1 dcache ports (ports as in the number of
read/write requests that a physical cache can service at one time, not
ports as the abstraction gem5 uses to connect memory devices). At the
moment, the simple cache model will service as many requests as the O3
CPU makes (unfeasible in the real world). There is a previous discussion
on a related topic here:
http://www.mail-archive.com/gem5-users@gem5.org/msg04107.html
The O3 CPU does have a parameter called cachePorts that attempts to
limit the number of dcache accesses per tick, but it gets set to 200
(inorder uses 2), and some of the code in the LSQUnit bypasses the limit
altogether. There's a related patch on the reviewboard (#1422) that
controls the number of accesses to the L1 cache, but it seems to have
stagnated.
My questions are:
*Have I completely misunderstood what's going on?
*Is an unlimited number of dcache accesses actually a problem? Does it
really matter that the number of accesses is occasionally
unrealistically high?
*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?
Thanks,
Erik
--
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
