On Sept. 26, 2012, 3:24 p.m., Andreas Hansson wrote:
I'm not too thrilled about this. Could you explain why we cannot rely on
the global time keeping here? I'm not understanding the issue...
Andreas Hansson wrote:
I'm even inclined to create a ResettableClockedObject in between
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1435/
---
(Updated Oct. 4, 2012, 8:29 a.m.)
Review request for Default.
Description
On Sept. 26, 2012, 3:24 p.m., Andreas Hansson wrote:
I'm not too thrilled about this. Could you explain why we cannot rely on
the global time keeping here? I'm not understanding the issue...
I'm even inclined to create a ResettableClockedObject in between ClockedObject
and the Ruby
Is there no other way Ruby could restore the cache state without advancing
time?
No. Setting ruby state requires you to step through the necessary transient
states and there is no clear way to know when all those transient states have
been completely stepped through without waiting for
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1435/#review3525
---
I'm not too thrilled about this. Could you explain why we cannot rely on
On Wed, 26 Sep 2012, Andreas Hansson wrote:
I'm not too thrilled about this. Could you explain why we cannot rely on the
global time keeping here? I'm not understanding the issue...
You need to understand how ruby warms up the caches on a checkpoint
restore. The checkpoint records
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1435/#review3532
---
Ship it!
Ship It!
- Brad Beckmann
On Sept. 24, 2012, 5:53 p.m.,