Re: [Gems-users] some queries about MOSI_SMP_bcast

[Brinda Ganesh <brinda_ganesh@xxxxxxxxx>]

Is there anyway to test the coherence framework for
its corner cases using either the tester exec
framework or otherwise - without using the entire
simics framework?

Thanks for all the help
Brinda

--- Mike Marty <mikem@xxxxxxxxxxx> wrote:

> Ok, I understand.  For writebacks, the cache
> controller in
> MOESI_SMP_directory will issue a PUT control message
> to the
> directory/memory controller.  The directory
> controller will ack this PUT
> message and then the cache controller will send the
> data and deallocate
> the TBE.  You are correct in that the writeback ack
> is tied to the
> directory state in that it will only nack the
> writeback if the directory
> is forwarding a request to the cache.
> 
> You are asking if you can keep the TBE allocated to
> possibly nack the
> actual writeback data.  In general, you can keep
> TBEs allocated as long as
> you want.  As an example, MOESI_CMP_token implements
> a non-speculative
> delay (MM_W and M_W) and keeps the TBE allocated
> longer than necessary.
> 
> It may be possibly to nack the writeback data rather
> than the initial
> writeback control message (PUT).  However I will
> warn you that there are
> deadlock issues when dealing with writebacks.  Many
> systems and protocols
> assume, when reasoning about virtual networks, that
> the writeback data
> message can always be sunk.
> 
> --Mike
> 
> 
> > Im assuming that the action l_writeDataToMemory is
> the
> > actual action which initiates a write to dram.
> This
> > action is initiated when a message appears on the
> > unblock queue. The cache controller places a
> message
> > on the queue (qq_sendTBEtoMemory) and then
> deallocates
> > the TBE.
> >
> > The writeback acks from the directory controller
> do
> > not seem to be tied with the memory controller
> > behavior but rather with the directory state.
> >
> > Thanks
> > Brinda
> >
> > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> >
> > > I'm confused.  The protocol should only
> deallocate
> > > the TBE (MSHR) when it
> > > receives data and does the callback to the
> > > processor.  Where do you see it
> > > deallocating as soon as the write is issued to
> > > memory?
> > >
> > > --Mike
> > >
> > >
> > > > Hi
> > > >
> > > > I have been playing around with the
> > > > MOESI_SMP_directory protocol and adding the
> > > NACK/Retry
> > > > concept in.
> > > >
> > > > I noticed that the protocol deallocates the
> TBE as
> > > > soon as a write is issued to memory. I was
> > > wondering
> > > > if postponing this deallocation to after it
> goes
> > > > through the memory system , and adding the
> concept
> > > of
> > > > dram nacks for the write request would create
> some
> > > > sort of incorrect state.
> > > >
> > > > Thanks
> > > > Brinda
> > > >
> > > > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> > > >
> > > > > Brinda,
> > > > >
> > > > > > I'm basically integrating our dram
> simulator
> > > > > framework
> > > > > > into gems. I integrated our simulator into
> the
> > > > > > MOSI_SMP_bcast cache coherence protocol.
> It
> > > all
> > > > > works
> > > > > > except when the dram system cannot handle
> a
> > > > > request
> > > > > > and asks the cache hierarchy to retry it
> > > later. I
> > > > > > currently have a bad hack to handle this
> but
> > > was
> > > > > > looking to see if any of the SMP protocols
> > > handle
> > > > > > retrys.
> > > > > >
> > > > >
> > > > > MOESI_SMP_token might work with no
> > > modifications.
> > > > > The Memory controller
> > > > > can simply ignore a request and the token
> > > coherence
> > > > > protocol would just
> > > > > time-out and try again.  However if you do
> use
> > > this
> > > > > protocol, set the
> > > > > g_RETRY_THRESHOLD to something higher than 1
> > > (like
> > > > > maybe 10).  After some
> > > > > number of retries specified by this
> parameter,
> > > the
> > > > > token coherence
> > > > > protocol will revert to a heavy-weight
> request
> > > > > guaranteed to succeed...I
> > > > > suppose this heavy-weight request might not
> work
> > > in
> > > > > your DRAM scheme as
> > > > > your DRAM controller would have to respond
> to
> > > this
> > > > > invoked requeset when
> > > > > it is able to (but doesn't have to right
> away).
> > > > >
> > > > > Otherwise without thinking about this much,
> I
> > > would
> > > > > think that a
> > > > > directory-based protocol might be more
> > > > > straightforward to implement a
> > > > > nack/retry.
> > > > >
> > > > > > You had mentioned in your email that you
> had
> > > built
> > > > > SMP
> > > > > > protocols in the past which handled acks
> etc.
> > > > > Would it
> > > > > > be possible for you to send me a version
> of
> > > these
> > > > > > protocols? It would definitely help me in
> my
> > > > > > integration process.
> > > > > >
> > > > >
> > > > > With have dozens of old protocols in our
> > > "attic".
> > > > > The problem is that the
> > > > > Ruby interfaces have changed requiring each
> > > protocol
> > > > > be modified to work
> > > > > with the latest release of GEMS.  For
> example we
> > > > > have a protocol based on
> > > > > the SGI Origin MESI protocol which does
> > > > > Nacks/Retries.  If you wanted, I
> > > > > could probably send this to you but it would
> > > _not_
> > > > > work.
> > > > >
> > > > > It would probably just be easiest to take
> > > > > MOESI_SMP_directory, add a NACK
> > > > > response instead of the normal DATA
> response.
> > > Then
> > > > > in the cache
> > > > > controller upon receiving the NACK, either
> issue
> > > the
> > > > > retry right away or
> > > > > schedule a timeout to wake up some X cycles
> > > later to
> > > > > issue the retry.  If
> > > > > you want some more pointers on doing this,
> let
> 
=== message truncated ===



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com