Hi all,

I am currently studying the MOESI_CMP_directory protocol in ruby. Based on the 
documentation, this protocol supports non-inclusive cache hierarchy. There are 
several states that represents a cache block can resides in L1(s) without being 
present in L2 (e.g., states ILX, ILO, ILS, ILOS, ILOSX, ILOSX).  Because the 
non-inclusive protocol provides additional directory (defined as structure 
localDirectory in src/mem/protocol/MOESI_CMP_directory-L2cache.sm) to track the 
blocks that are replaced in L2 while still being presented in L1, I thought 
such directory entry is allocated when L2 replacement happened. But looking at 
the implementation, some transitions are confusing:

  transition(ILS, L2_Replacement) {
    y_copyCacheStateToDir;
    rr_deallocateL2CacheBlock;
  }

  transition(ILX, L2_Replacement )  {
    y_copyCacheStateToDir;
    rr_deallocateL2CacheBlock;
  }

  transition({ILO, ILOS}, L2_Replacement )  {
    y_copyCacheStateToDir;
    rr_deallocateL2CacheBlock;
  }

First, since the state IL* represents the cache block is not exists in L2, why 
does the code still copy the state from cache to dir?
Second, the action "y_copyCacheStateToDir" is using function:

  void copyCacheStateToDir(Entry cache_entry, Addr addr) {
    assert(localDirectory.isTagPresent(addr) == false);
    assert(is_valid(cache_entry));
    localDirectory.allocate(addr);
    DirEntry dir_entry := getDirEntry(addr);
    dir_entry.DirState := cache_entry.CacheState;
    dir_entry.Sharers := cache_entry.Sharers;
    dir_entry.Owner := cache_entry.Owner;
    dir_entry.OwnerValid := cache_entry.OwnerValid;
  }

in which one assert is used for checking the cache block existence in L2, 
however, since the IL* is defined an invalid state, this function call could 
raise assert failure intuitively in my understanding. Nevertheless, I can 
successfully run simulations with such protocol.

Anyone could explain the answer is appreciated in advance.

Regards,
Wei


_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to