Re: [Gems-users] invalidating a cache block

[Dan Gibson <degibson@xxxxxxxx>]

I have never personally tried calling these functions from outside the protocol specification -- it might work, and it might not. It seems like an approach that is worth trying, at least.

As for worrisome states (besides M and O) -- there could be several more because of transient states like MM, but this depends on the protocol. Several protocols enter blocking states to avoid certain directory races. You would have to wait for these transients to resolve before you could force the writeback.

Here is another suggestion that might work: Since ruby uses true LRU replacement, you could issue 'phantom' requests to the cache in such a way that the associativity is saturated. For instance, if your workload uses physical addresses 0 - 2^32-1, and your L1 is 4-way associative, then four requests that map to the same set but have addresses > 2^32-1 would effectively evict all the /real/ blocks from the cache. Best of all, if each processor has its own 'phantom' region, the coherence overhead would be minimal. On the other hand, if your protocol is inclusive, this could lead to polluting the L2, and you would have to lie to ruby when you specify g_MEMORY_SIZE_BYTES.

Regards,
Dan

Mladen Nikitovic 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?

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?

Regards,
Mladen

Mladen Nikitovic wrote:
  

The result I would like to achieve is the consequence from (temporarily) 
disabling the power lines of the cache, which would mean that all data 
would be lost. To avoid any inconsistency I need to invalidate all 
entries and write back any data that is modified (or maybe also owner of 
shared data?) before shutting down.

Couldn't the same processor that is being disabled do the necessary 
actions just before the shutdown? If yes, then the question is how to 
trigger the writebacks. My approach was to trigger the protocol actions 
somehow, but I don't know how to actually do it nor do I know which 
function does this.

Regards,
Mladen

Dan Gibson wrote:
  
    

You could 'force' another processor to issue stores to all the blocks 
in the cache you need to invalidate. Of course, I'm not sure if this 
would be applicable, since I don't know why you want the blocks 
invalidated.

Mladen Nikitovic wrote:
    
      

Sorry, I forgot to actually specify my question :)

Since I don't belive the stxa instruction will fully generate the 
desired events I wonder how I can achieve that in ruby. How can I 
trigger the protocol to do the invalidation and possible writebacks for me?

Regards,
/Mladen

Mladen Nikitovic wrote:
  
      
        

Hi,

I would like to go through a cache and invalidate each entry 
block-by-block. I would like to do it in a way such that necessary 
events within ruby (replacements if needed) are triggered.

I found a code in opensolaris that is supposed to flush the cache (see 
below) but I suppose that the instruction stxa will not trigger the 
expected events in GEMS?

#define CH_CACHE_FLUSHALL(arg1, arg2, tmp1)

  sub arg1,arg2,tmp1;
1:
  stxa %g0, [tmp1]ASI_DC_TAG;
  membar #sync;
  cmp %g0, tmp1;
  bne,pt %icc, 1b;
  sub tmp1, arg2, tmp1;


I'm using the MOESI_CMP_directory protocol.

Thanks.

Regards,
Mladen




_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto: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.

  
    
        
          

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto: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.


  
      
        

-- 
http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson> [esc]:wq!
  
------------------------------------------------------------------------

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

  
    
      

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

  
    

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


  

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!