These are not intended to model the network latency -- that was my
point. The network latency is modeled by links and switches between the
core and the remote L2 module.
The L2 hit latency will depend on the protocol. You have to look at
what transitions (and actions) occur on an L1 miss that hits in the L2,
and see what latencies are inserted for each action.
For example, consider the MOSI_SMP_bcast-cache.sm file. Here's what I
think happens:
(1) CacheRequest message reaches the head of the mandatory queue.
(2) Controller determines that it's a load, and that the line is present
in the L2 (but not in the L1D). Therefore, it "triggers" an L2_to_L1D
event (on the same cycle).
(3) Let's suppose that the line is in state S in the L2. The L2_to_L1D
event causes a transition to the same state (S), but the side effect is
to copy the block from L2 to L1D.
(4) On the next cycle, the controller wakes up again, because there's
still a message in the mandatory queue (since we didn't yet remove it).
(5) This time, the controller sees that the line is in L1D in the right
state, so it triggers a Load event. This causes a transition to occur
that handles a cache hit (i.e., calls the Sequencer.readCallback method,
etc.) and pops the mandatory queue.
Therefore, I believe (but am not absolutely sure) that the minimum L2
hit latency would be 2 cycles -- one to transfer the data to L1, and one
to handle the "hit" in L1. (Could be more if there was a queueing delay
in the mandatory queue...) I hope the GEMS developers will correct any
mistakes in my interpretation of the code.
The L2_*_LATENCY parameters don't come into play -- they are not used in
any of the actions that handle this memory transaction.
...Greg
Thomas Yeh wrote:
Your description of those 2 latencies makes sense. But there still has to
be latency for accessing the banks. How is this represented?
I greped "LATENCY" on MOESI_CMP_direcotry files, and I only see:
DIRECTORY_LATENCY,
MEMORY_LATENCY,
L2_RESPONSE_LATENCY,
L2_REQUEST_LATENCY,
L1_RESPONSE_LATENCY,
L1_REQUEST_LATENCY.
can anyone explain at a high level how this protocol works as far as
timing goes? I realize the network latency can be modelled by these
request and response latencies. But what is the latency of a load that
hits the local L2? I believe L1 latencies are 1 cycle since fasthit is
enabled.
thx,
Tom
On Thu, 12 Oct 2006, Greg Byrd wrote:
Thomas Yeh wrote:
I see that L2_REQUEST_LATENCY and L2_RESPONSE_LATENCY are used.
When I change the size of each bank that's placed locally with each core,
I would like to change the latency of accessing each bank.
Which parameter should I change?
I think that these parameters only deal with the delay inside the L2
controller itself. When an event occurs that causes a request message
to be sent out, there is a delay of L2_REQUEST_LATENCY between the event
and when the request message is enqueued. Likewise for a response
message and L2_RESPONSE_LATENCY.
My guess is that all of your banks are actually the same, and that the
latency difference will be the amount of time that it takes to reach a
bank from a particular core. If that's the case, then that latency
should be reflected in the interconnection network, not in the L2 module
itself.
Also, I see a directory cache latency in the ruby stats file. It defaults
to 80. Is the directory assumed to be in memory?
Yes.
...Greg
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}