Lide Duan wrote:
Thank you, Mike! Please see inline...
On 9/6/07, Mike Marty <mikem@xxxxxxxxxxx> wrote:
I have been studying the protocol MOESI_CMP_directory recently. I hope
you can give me some help on the following questions:
1. It's said that this protocol is a "two-level directory protocol",
so what does the "two-level" refer to? I found that any entry of L1
cache, L2 cache or memory has certain fields (e.g. CacheState,
Sharers, Owner, etc) to record the coherence information of each cache
line, then there are 3 levels. But there is only one localDirectory in
the L2 cache, so I got confused with the "two-level directory".
Directory coherence between CMPs and Directory coherence within a CMP.
For an explanation, see this paper:
http://www.cs.wisc.edu/multifacet/papers/hpca05_cmp_token.pdf
2. Some previous posts mentioned that the localDirectory in the L2
cache approximates L1 shadow tags. Could you explain more about this?
Why do we need such a directory in the L2 cache considering that all
the coherence information has been recorded in the entries of
CacheMemory?
The first-level L2 directory *can* be implemented in the L2 cache tags if
inclusion is enforced. I have a version of MOESI_CMP_directory that does
exactly this, but I have not (yet) incorporated into a release of GEMS.
The released version of MOESI_CMP_directory does not enforce inclusion.
The hackish implementation will copy directory state from the tag to the
localDirectory when an L2 line is evicted. In reality, you wouldn't
implement it this way in hardware.
So basically the localDirectory is used to contain the states of the
recently evicted L2 blocks, thus improving the overall system
performance, because the system will change the L2 block to be evicted
if it is found in the shadow tags, i.e. localDirectory. Am I right? So
It isn't necessary to have this structure for the correctness of the
system, is it?
No. There *must* be directory state at the L2 controller for all cached
L1 blocks. localDirectory holds the directory state for blocks not
present in the L2. This is meant to approximate shadow tags. The
target system would not have directory state in L2 tags even though it
is coded this way. There is no good reason why I coded it this way...if
I had the time to re-code this protocol, I would.
I am wondering has Ruby prioritized the different VNs? I remember that
the Throttle in the network source code satisfies the bandwidth
requirements from VN3 to VN0, which means the VN3 gets the highest
priority, but these priorities will be inverted if the variable
m_wakeups_wo_switch in Throttle exceeds a constant
PRIORITY_SWITCH_LIMIT. Is there anywhere else related to the
prioritized VNs? Why did you do that?
Actually I observed the following msgs in the simulation for each VN
(X means not zero) ;
Request_Control [ X X 0 0 ]
Response_Control [ 0 0 X 0 ]
Writeback_Control [ X X X 0 ]
Forwarded_Control [ X 0 0 0 ]
Invalidate_Control [ X 0 0 0 ]
Unblock_Control [ 0 0 X 0 ]
Response_Data [ 0 0 X 0 ]
ResponseL2hit_Data [ 0 0 X 0 ]
ResponseLocal_Data [ 0 0 X 0 ]
Writeback_Data [ 0 0 X 0 ]
I am confused with the different msgs. For example, is
Writeback_Control used for L2 cache to write back to the memory? Is
there any writeback between L1 and L2? What's a Forward_Control and
Unblock_Control? Some specific examples would be helpful.
Yes, there is writeback between L1s and L2s, and L2s and memory.
Three-phase writebacks for all cases. That is why there are
Writeback_Control messages.
Forward_Control is a Forward message. Unblock_Control is for messages
to unblock the blocking directories.
--Mike
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}