Re: [Gems-users] invalidating a cache block

[Mladen Nikitovic <mladen@xxxxxx>]

Mike Marty wrote:
> On Jan 9, 2008 3:43 AM, Mladen Nikitovic <mladen@xxxxxx> wrote:
>
>   
> > I have found a possible solution:
> >
> > I noticed that there is a section in the generated file
> > L1Cache_Transitions.C that handles L1Cache_Event_L1_Replacement and
> > L1Cache_Event_L1_Writeback events with the following actions:
> >
> > i_allocateTBE(addr);
> > d_issuePUTX(addr);
> > x_copyDataFromL1CacheToTBE(addr);
> > ff_deallocateL1CacheBlock(addr);
> > return TransitionResult_Valid;
> >
> > I have seen that these functions/methods (i_allocTBE etc) are
> > implemented in the L1Cache_Controller.C file, which means that I should
> > be able to call them via a L1cache_controller object, right?
> >
> >     
> I don't recommend this approach.  The protocol needs to go through its
> state-machine actions for handling replacements.  The Ruby Sequencer
> currently issues either a "Load", "Store", or "Ifetch" request to L1
> controllers via the mandatory queue.  I think adding a fourth "Invalidate"
> request is a better approach. The in_port processing logic would then just
> trigger an L1_Replacement event and the protocol will take care of the
> rest.
>
>
>
>   
 Ok, I just want to confirm that I have understood what needs to be 
done here.
First, in order to send a request to the L1 controller via the mandatory 
queue I can do something like this, right?
m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(msg, latency);

Then, to support the Invalidate request I intend to add a 
CacheRequestType_Invalidate definition to the file CacheRequestType.h 
file, add a case for this in the string_to_CacheRequestType and 
CacheRequestType_to_string functions in the CacheRequestType.C
Finally, when the definitions and string conversions are in place I can 
add an if-case that catches the Invalidate message in file 
MOESI_CMP_directory-L1Cache.sm protocol file
 Event mandatory_request_type_to_event(CacheRequestType type) {
   if (type == CacheRequestType:LD) {
     return Event:Load;
   } else if (type == CacheRequestType:IFETCH) {
     return Event:Ifetch;
   } else if ((type == CacheRequestType:ST) || (type == 
CacheRequestType:ATOMIC)) {
     return Event:Store;
   } else if(type == CacheRequestType:INVALIDATE) {
     return Event:L1_Replacement;
   } else {
     error("Invalid CacheRequestType");
   }
 }

Will this be enough to do the trick?

I have another question related to this. I found another file (in the 
generated catalog) called L1Cache_mandatory_request_type_to_event.C that 
looks like this:
#include "Types.h"
#include "Chip.h"
#include "L1Cache_Controller.h"

L1Cache_Event 
L1Cache_Controller::L1Cache_mandatory_request_type_to_event(CacheRequestType 
param_type)
{
 if ((param_type == CacheRequestType_LD)) {
   return L1Cache_Event_Load;
 } else {
   if ((param_type == CacheRequestType_IFETCH)) {
     return L1Cache_Event_Ifetch;
   } else {
     if (((param_type == CacheRequestType_ST) || (param_type == 
CacheRequestType_ATOMIC))) {
       return L1Cache_Event_Store;
     } else {
               cerr << "Runtime Error at 
../protocols/MSI_MOSI_CMP_directory-L1cache.sm:252, Ruby Time: " << 
g_eventQueue_ptr->getTime() << ": " << ("Invalid CacheRequestType") << 
", PID: " << getpid() << endl;
char c; cerr << "press return to continue." << endl; cin.get(c); abort();

;
     }
   }
 }
}

It is very similar to the if-else switch statements in the protocol. I 
could add another clause here also but then I noticed that there is 
already a L1Cache_Event_INV event defined in L1Cache_Event.h. The 
problem I find here is that I could choose to translate the 
CacheRequestType_INVALIDATE into either  a L1Cache_Event_INV or 
L1Cache_Event_L1_Replacement. Should I choose the latter to be 
consistent with the changes in the protocol? What happens if I choose 
the former option? do I need to make any changes at all to this file?
Regards,
M

> > This is what I propose:
> >
> > go through the L1 cache block-by-block {
> >  if I find a block that need to be written back I call the methods
> > (i_allocateTBE, d_issuePUTX, x_copyDataFromL1CacheToTBE, and
> > ff_deallocateL1CacheBlock) via the corresponding controller in the
> > L1Cache_Controller_vec vector.
> > }
> >
> > If this is correct, I have a follow-up question since I'm not a
> > coherence protocol expert: My initial thought was to perform a writeback
> > only when I see a block that is in the M and O state, but I might have
> > missed any other vital states. Also, there are many intermediate states,
> > do I need to consider those possibilities also?
> >
> >     
> MOESI_CMP_directory does not do silent S replacements.  It sends a control
> message to keep directories up-to-date.
>
> --Mike
>
>   
> ------------------------------------------------------------------------
> _______________________________________________
> 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.
>
>