Hello Andreas,
Ok. So below code make sure that the next scheduling decision happens early
enough. Is that correct?
// Update the minimum timing between the requests, this is a
// conservative estimate of when we have to schedule the next
// request to not introduce any unecessary bubb
Hi Prathap,
If we have no row hits left in the queue, the open-adaptive (and
close-adaptive) policy will auto precharge. The next scheduling decision will
happen early enough that we can hide any preparation needed to not introduce
bubbles on the bus. Thus, the activate will happen early enough
Hi
I am running Bbench on ICS Android Image on Gem5. I am not sure whether the
webpage timings are accurate (which comes on result page of Bbench, at the
end of test).
My reason for asking is that I ran Amazon, BBC and CNN individually and all
together. The following were the reading:
Individual:
Hello Andreas,
I am still not very clear.
>> If we have not already precharged, we need to take the hit and do it now.
What If we don't have any row hits left in the queue? I agree that with
open-adaptive policy, the Bank1 will be auto precharged. According to the
code snippet below, it still has
Hi Prathap,
The expression ensures that we do not “go back in time” when deciding to
precharge the bank. If we have not already precharged, we need to take the hit
and do it now. For the access pattern you describe, with an closed-adaptive or
open-adaptive page policy we will issue the last col
Hi Rahul,
I do not believe McPAT supports DVFS properly, so in any case your mileage may
vary.
My guess would be that target_core_clockrate is what the cores where designed
to achieve as their max clock rate.
Andreas
From: gem5-users
mailto:gem5-users-boun...@gem5.org>> on behalf of
rahul s