Hi Chris,
That does sound rather unfortunate. My first guess would be that it could be
because of unfortunate event re-ordering. As you know, there is no clear clock
domain crossing in gem5. Instead, we simply rely on modules scheduling the next
event on the following clock edge. I know that the interplay between the CPU
pipeline events and the cache events can be rather delicate (what happens first
of a list of things all happening at time T), so perhaps it is some subtle
interplay between events arriving at a certain clock, and being dealt with at
another one, and somehow getting lost in the ratio between the two.
Could you perhaps do some more tracing/debugging to try and pin this down?
Also, could you clarify if the loads/stores that take longer are to a cache in
the same clock domain as the CPU.
Thanks,
Andreas
From: Chris Torng <[email protected]<mailto:[email protected]>>
Reply-To: gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Monday, 28 October 2013 20:16
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
Subject: [gem5-users] Unexpected Latencies for Dynamic Frequency Scaling
Hey everyone,
I've done some development starting from changeset 9793 (this changeset
introduced clock domains). I added a function to set the clock period of a
clock domain. Clocked objects can use this function to dynamically set the
clock period of their clock domain at runtime.
I configured a quad-core system in SE mode, with four InOrderCPUs with private
caches, running a MIPS-like ISA that I added support for. The system has four
tiles but five clock domains -- one for each tile and one for a simple DVFS
controller that manages the frequencies of all tiles. Sometime down the line,
I'm hoping to push my changes for others to use, unless someone else does it
better than I did.
During my development, I'm noticing that setting the clock period of a clock
domain to certain frequencies introduces latencies between the CPU and caches
living in that clock domain. It looks like loads and stores take a really long
time to return at the new frequency, but it seems like it will only happen for
certain new frequencies. I'm only using simple memory and I don't touch the
Ruby memory system.
For example:
Starting at a nominal frequency of 625MHz (1600 Ticks) and moving up to a
frequency of 1250MHz (800 Ticks) causes cycles to occur twice as often, and
memory latencies seem to scale correctly.
On the other hand, when starting at a nominal frequency of 625MHz (1600 Ticks)
and moving up to a frequency of 800MHz (1250 Ticks), I can easily verify from
an Exec debug dump that the cycles occur at the new 1250 Tick period. However,
loads and stores to and from cache suddenly take tens or hundreds of cycles to
return.
My best guess is that there is some kind of division operation of clock periods
that loses precision in a type cast, and then is used to model latency.
However, I'm not too fluent with our latency models.
Does anyone know off the top of their heads whether there is some clock_period
dependent calculation in the memory system that might make this happen?
Thanks!
Chris Torng
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
