Re: [Gems-users] some queries about MOSI_SMP_bcast

[Mike Marty <mikem@xxxxxxxxxxx>]

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
> > me
> > > > know.  Start by adding
> > > > the NACK to CoherenceResponseType in
> > > > MOESI_SMP_directory-msg.sm.  Create
> > > > an action in MOESI_SMP_directory-dir.sm to send
> > a
> > > > NACK.  And so on...
> > > >
> > > >
> > > > --Mike
> > > >
> > > >
> > > >
> > > > > Thanks
> > > > > Brinda
> > > > >
> > > > > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> > > > >
> > > > > > > I was trying to better understand the
> > workings
> > > > of
> > > > > > the
> > > > > > > MOSI_SMP_bcast protocol and have a couple
> > of
> > > > > > > questions.
> > > > > > >
> > > > > > > What exactly happens when a request is
> > > > recycled on
> > > > > > the
> > > > > > > network queue i.e. action
> > > > zz_recycleMandatoryQueue
> > > > > > in
> > > > > > > MOSI_SMP_bcast.sm.
> > > > > > >
> > > > > >
> > > > > > Recycling a request pops it from the head of
> > the
> > > > > > queue and places it at
> > > > > > the end of the queue, and schedules a wakeup
> > in
> > > > case
> > > > > > the controller
> > > > > > doesn't wake up the next cycle anyways.
> > > > Essentially
> > > > > > recycling a request
> > > > > > allows our queues to be non-FIFO and allows
> > one
> > > > > > request for cache line to
> > > > > > block while others are serviced.
> > > > > >
> > > > > >
> > > > > > > What parameter can be used to limit the
> > number
> > > > of
> > > > > > > outstanding cache requests?
> > > > > > >
> > > > > >
> > > > > > The number of requests issued to the memory
> > > > system
> > > > > > can be controlled by
> > > > > > the g_SEQUENCER_OUTSTANDING_REQUESTS
> > parameter.
> > > > > > However the L1 cache
> > > > > > controller itself can control how many MSHRs
> > are
> > > > > > available with the
> > > > > > NUMBER_OF_TBES parameter.
> > > > > >
> > > > > >
> > > > > > > What is the equivalent of the mshr in
> > ruby?
> > > > > > >
> > > > > >
> > > > > > a TBE.  Each protocol will have a TBETable
> > in
> > > > the
> > > > > > cache controller.
> > > > > >
> > > > > > > Finally unrelated to the MOSI_SMP_bcast
> > > > protocol -
> > > > > > are
> > > > > > > there any SMP protocols which are part of
> > your
> >
> === message truncated ===
>
>
>
>
> ___________________________________________________________
> How much free photo storage do you get? Store your holiday
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>