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.
>
>
>   
 That sounds like an much simpler approach than my original idea. I 
will try it tomorrow (its getting late here) and see if I can make it 
work. Thanks!
>   
> > 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.
>
>