Re: [Gems-users] How does store hit go from Sequencer to L1 in Ruby

[Javier Merino <jmerino@xxxxxxxxxxxxx>]

Tushar Krishna wrote:
> Hi,
> I am trying to track memory requests as they move from the Sequencer to 
> L1 to L2 etc.
> I am looking at the MOESI_CMP_directory protocol, but the question I 
> want to ask is more general.
> 
>  From what I understand from the code, for any memory request, the 
> sequencer checks if the line is present in L1. If no, it forwards it 
> down to the L1 cache controller which issues the appropriate coherence 
> actions. But if the line is present in L1, it just returns a hit without 
> invoking the L1 cache controller ( for 
> REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH set to false).
> 
> I am talking about the following piece of code in system/Sequencer.C in 
> the function doRequest(CacheMsg& request)
> 
> ...
> hit = tryCacheAccess(line_address(request.getAddress()),
>                        request.getType(),
>                        request.getProgramCounter(),
>                        request.getAccessMode(),
>                        request.getSize(),
>                        data_ptr);
> 
>   if (hit && (request.getType() == CacheRequestType_IFETCH || 
> !REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH) ) {
>     DEBUG_MSG(SEQUENCER_COMP, MedPrio, "Fast path hit");
>     hitCallback(request, *data_ptr, GenericMachineType_L1Cache, thread);
>     return true;
>   }
> ...
> 
> *But suppose there is a write request (store) hits a line in L1 in state 
> E*. *Where does the state change from E to M and informing the directory 
> etc take place if L1 cache controller is not invoked?*

If the L1 is in E, its AccessPermission is Read_Only (see the setState()
function in MOESI_CMP_directory-L1cache.sm for example).
Sequencer::tryCacheAccess() calls CacheMemory::tryCacheAccess() which
only returns true if the line is present and:

    if(entry.m_Permission == AccessPermission_Read_Write) {
      return true;
    }
    if ((entry.m_Permission == AccessPermission_Read_Only) &&
        (type == CacheRequestType_LD || type ==
CacheRequestType_IFETCH)) {
      return true;
    }
    // The line must not be accessible

so tryCacheAccess() returns false, there's no fast path hit so the L1
cache controller is invoked.


> Another quick related question: Are the L1's write-through or 
> write-back? If a store hits in L1 in state M, does a write back take 
> place? Again, how does it take place if the sequencer just returns a hit 
> instead of going to the L1 Cache Controller (with 
> REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH set to false).

All the protocols I've used in GEMS implement L1 write-back caches. The
MOESI_CMP_directory you mentioned before is write-back. I guess you'd
have to set REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH to true in order to
make a write-through protocol.

Hope this helps,
Javier Merino

> Thanks
> Tushar
> _______________________________________________
> 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.
>

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente