ruby: set default latency for ruby caches
Review Request #2796 - Created May 11, 2015 and updated
| Information | |
|---|---|
| Tony Gutierrez | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10853:1ce6a4401f97 --------------------------- ruby: set default latency for ruby caches Set to 0 since many protocols do not use the parameter.
Ship It!
This change seems to go away from its apparent aim:
First, this patch seems to be aimed at correcting some common confusion: The RubyCache latency parameter is strange, because the cache itself does not enforce the latency. Instead, the protocol controllers enforce cache access latencies, which can be defined either as part of the cache or as parameters to the controller. This current organization disagregates the accountability for enforcing reasonable cache read/write latency, and makes it very confusing/difficult to validate memory access times.
However, just defaulting the RubyCache latency to 0 doesn't fix any confusion about protocol memory access time validation, and actually encourages poorer use of the latency parameter. Right now, when I open any configs/ruby/*.py protocol file, I see a latency declaration in a cache with a comment that says the latency is ignored (except sometimes for fast path hits...?). Why declare a cache latency if it won't be used?! This patch could eliminate the need to forward declare cache latencies, but the cache declaration itself must remain. This means that this patch would leave numerous cache declarations with confusing, unused latency declarations even though cache latencies now default to 0 cycles (which - I suppose - could be used to indicate that the latency is not used, but again, what should happen if I change the latency?). Worse, new protocols might not even define a cache's unused latencies, leaving the user baffled about why they can change a cache's latency without it affecting simulated system performance.
We should be aiming to either use or lose the RubyCache latency parameter, but not settle somewhere between. Here are the two extremes:
1) All RubyCache latencies must be defined and enforced by their respective protocols. In config files, this would involve passing the RubyCache's latency variable as a parameter to the controllers that need them. In the protocol files, controllers could also enforce these latencies by referencing the cache's latency during enqueue to a buffer. This would actually make memory access times depend on the cache latency parameter (though in practice, it's hard to make sure protocols do this).2) Get rid of the RubyCache latency parameter altogether. This would require protocols to parameterize any cache latencies (most already do, though sometimes aggregated with other latencies, which is cumbersome and very fragile). This would side-step user confusion about the RubyCache latency variable.
The former option is probably better: We've added tag and data array resource conflicts to the RubyCache, so it is partially responsible for enforcing latencies already. Further, it would be easier to find and change a cache's latency rather than digging through a controller file to see how latencies are used and setting some aggregated parameter. Finally, the RubyCache's latency is saved to config.ini, so it would be easier to reference prior simulations for comparison and validation.
What's the reason for not removing the latency parameter altogether in this patch? From what I can tell it's used in exactly one place: the parameter is taken from the L1 cache (or whatever has the mandatory queue) and used to add latency when the memory request is initially injected into Ruby. If you are going to default to 0, I see no reason not to just remove the confusion altogether.
As far as I know, no protocol uses this parameter (correctly). Am I mistaken here?
I really hate changes that force all of the protocol-specific python config files to change, but in this case I think it's worth it.