Re: [Gems-users] Protocol with Directory Cache (again)


Date: Tue, 20 Feb 2007 15:20:26 -0600 (CST)
From: Mike Marty <mikem@xxxxxxxxxxx>
Subject: Re: [Gems-users] Protocol with Directory Cache (again)
for the ones that matter, yes.

--Mike


> Mike,
>
> thanks, I will do in this way. Just make sure I need to add this if.. else
> in every action, right?
>
> Legion
>
> On 2/20/07, Mike Marty <mikem@xxxxxxxxxxx> wrote:
> >
> > I've added a directory cache to one of my own protocols.  I added no
> > states.  Here is an example action.  Notice all it does is check to see if
> > dirCache contains the tag.  If so, it uses DIRECTORY_CACHE_LATENCY instead
> > of DIRECTORY_LATENCY
> >
> >
> >   action(f_forwardRequest, "f", desc="Forward request to owner") {
> >     peek(requestQueue_in, RequestMsg) {
> >       if (dirCache.isTagPresent(address) == false) {
> >         enqueue(forwardNetwork_out, RequestMsg,
> > latency="DIRECTORY_LATENCY") {
> >           out_msg.Address := address;
> >           out_msg.Type := in_msg.Type;
> >           out_msg.Requestor := in_msg.Requestor;
> >           out_msg.Destination.addNetDest(directory[in_msg.Address].Owner);
> >           out_msg.AckCount := directory[address].Sharers.count();
> >           if
> >
> > (directory[address].Sharers.isElement(map_L1CacheMachId_to_PrivateL2Cache(in_msg.Requestor)))
> > {
> >             out_msg.AckCount := out_msg.AckCount - 1;
> >           }
> >           APPEND_TRANSITION_COMMENT(in_msg.Requestor);
> >           APPEND_TRANSITION_COMMENT(" ");
> >           APPEND_TRANSITION_COMMENT(directory[in_msg.Address].Owner);
> >           out_msg.MessageSize := MessageSizeType:Forwarded_Control;
> >         }
> >       } else {
> >         enqueue(forwardNetwork_out, RequestMsg,
> > latency="DIRECTORY_CACHE_LATENCY") {
> >           out_msg.Address := address;
> >           out_msg.Type := in_msg.Type;
> >           out_msg.Requestor := in_msg.Requestor;
> >           out_msg.Destination.addNetDest(directory[in_msg.Address].Owner);
> >           out_msg.AckCount := directory[address].Sharers.count();
> >           if
> >
> > (directory[address].Sharers.isElement(map_L1CacheMachId_to_PrivateL2Cache(in_msg.Requestor)))
> > {
> >             out_msg.AckCount := out_msg.AckCount - 1;
> >           }
> >           APPEND_TRANSITION_COMMENT(in_msg.Requestor);
> >           APPEND_TRANSITION_COMMENT(" ");
> >           APPEND_TRANSITION_COMMENT(directory[in_msg.Address].Owner);
> >           out_msg.MessageSize := MessageSizeType:Forwarded_Control;
> >         }
> >       }
> >     }
> >   }
> >
> >
> >
> > > Hi,
> > >
> > > I finally make the RAC work, at least the tester and splash2 didn't
> > compain.
> > > thanks for the helps.
> > > Now I plan to add a directory cache. I do find one thread on this topic
> > in
> > > the archive, and Mike recommended:
> > > "You can change the getState() function in the Directory controller to
> > return
> > > a different state if the directory entry
> > > is cached. Actions triggered by events to these cached states will use a
> > > lower latency".
> > >
> > > However, I have concerns to the above solution. First, we need to
> > duplicate
> > > all Actions/Transitions and make changes
> > > everywhere. Second, maintaining a seperate set of states for directory
> > cache
> > > is quite nontrivial, may even raise problems
> > > at directory cache replacement. Therefore, I prefer to make changes in a
> > > centralized place.
> > >
> > > Here are my random thoughts. In getState, if we make directory cache hit
> > as
> > > the base case, and add some
> > > latency (directory latency - directory cache hit latency) at misses,
> > this
> > > should be a close approximation. However, since
> > > getState is not an event, I don't find a easy way to recycle (retry
> > after xx
> > > cycles) it.  As a result,  I am thinking of adding
> > > latency when poping the message from in-port. Basically, we add a new
> > > function in MessageBuffer class say
> > > cust-recycle(num_cycles). When peeking in-ports, we first check the
> > > directory cache. If tag matches, we pop the messages
> > > as usual, else, we cust-recycle this message for (directory latency -
> > > directory caches hit latency) cycles. Will this work?
> > >
> > > you guys are much more experienced on gems, any feedback/advice is much
> > > appreciated.
> > >
> > > thanks
> > > Legion
> > >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding "site:
> > https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> >
> >
>
[← Prev in Thread] Current Thread [Next in Thread→]