Re: [Gems-users] some queries about MOSI_SMP_bcast

[Brinda Ganesh <brinda_ganesh@xxxxxxxxx>]

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
> > > 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
> >
> _______________________________________________
> 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