Re: [Gems-users] some queries about MOSI_SMP_bcast

[Mike Marty <mikem@xxxxxxxxxxx>]

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
> > release
> > > which can handle retry requests?
> > >
> >
> > We've certainly implemented Nack/Retry directory
> > protocols before.  But it
> > doesn't appear that the SMP protocols we include
> > with the release do this.
> >
> > The token coherence protocols retry requests.
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> >
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >
>
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>