Re: [Gems-users] Cache replacement policy

["Mike Marty" <mikem@xxxxxxxxxxx>]

Considering the cache state is a possible optimization to the LRU
algorithm.  Yes, ideally Invalid lines are replaced first.  However if the
hardware implements a pseudo-LRU tree, it is not obvious how this would be
done.

--Mike

> Dear Gems Users,
>
> I have a question about the replacement policy used in the CacheMemory
> class (ruby/system/CacheMemory.h). A block can be allocated in a cache
> set when at least one line has "AccessPermission_NotPresent". In other
> case, the cacheProbe function is called to get the address of the block
> that will be evicted. This block is the LRU in the set. But what about
> the invalidated blocks ("AccessPermission_Invalid")? I think that they
> must be replaced earlier than valid blocks (MOES) without take in
> consideration the age of the block.
>
> In fact when I run the next trace (all blocks assigned to the same cache
> set),
>
> 0 0x400 0 LD
> 0 0x800 0 LD
> 3 0x800 0 ST
> 0 0x1200 0 LD
>
> with a two-way L1 cache, the last request causes the replacement in the
> L1cache-0 of the block 0x400 (in M state) keeping in cache the block
> 0x800 (in I state) because is more recent. Does this make sense? Am I
> losing something?
>
> Thank you very much!!
>
> Regards
>
> Alberto
>
> _______________________________________________
> 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.
>