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
| ![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}