Re: [Gems-users] changing the replacement policy

[Bradford Beckmann <beckmann@xxxxxxxxxxx>]

Sorry for the late response, I was out-of-town yesterday.

I did implement something similar to what you suggested before, so I can
say that does work.  However, instead of adding a field to cache memory, I
just added a new "On Hold"  AccessPermission type to indicate the block
chosen for eviction.  That way it is similar to us using the
AccessPermission_NotPresent type to indicate empty blocks.

Brad


On Wed, 22 Mar 2006, Milo Martin wrote:

> Perhaps you could add a field to the cache memory to remember which
> victim was last selected for each set in the cache.  That is, you
> keep returning the same replacement candidate of a set until it is
> actually replaced.
>
> - MMKM
>
> On Mar 22, 2006, at 12:01 PM, Mike Marty wrote:
>
> >> I was trying to change the cache replacement policy for
> >> MSI_MOSI_CMP_directory
> >> to random and I ran into problems. It looks like the operation of
> >> the protocol
> >> is dependent on the replacement policy being LRU. Multiple calls
> >> to cacheProbe
> >> should return the same candidate for replacement.
> >> Is that true or I am missing something? Are there other coherence
> >> protocols
> >> which do not have this problem?
> >>
> >
> > Ugh.  Definitely seems like a problem due to the lack of global
> > variables
> > in SLICC.  It isn't dependent on LRU, only that subsequent calls
> > (in the
> > same wakeup) to cacheProbe() return the same thing.  So any non-random
> > replacement policy would work.
> >
> > I'll think about this and get back to you if I happen to come up
> > with a
> > clean solution to using a random replacement policy.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>
> --
> Milo M. K. Martin (milom@xxxxxxxxxxxxx)
> http://www.cis.upenn.edu/~milom/
> Assistant Professor
> Computer and Information Sciences Department
> University of Pennsylvania
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>