Re: [Gems-users] flushing L1 caches

[Dan Gibson <degibson@xxxxxxxx>]

I do not know enough about how SLICC generates code to answer this question. If I were you, I'd look around for hooks that will allow you to query the size of the mandatory queue, and then sneak all your requests in when the queue is empty, but since I've never monkeyed with the mandatory queue directly I'm not sure it will work.

Regards,
Dan

Mladen Nikitovic wrote:

Is it possible to somehow "flush" the mandatory queue or wait until (via 
an indication) the outstanding requests have completed before I do the 
flush? Is it possible to follow the outstanding requests?

I do not want to break ruby :)

/M

Dan Gibson wrote:
  

There could be other replacements in progress, I suppose, that could raise this 
problem. It might be OK to simply remove the assertion altogether, though I 
cannot guarantee that will not break Ruby in strange and mysterious ways. The 
other way would be to force the system (maybe just the local L1) to quiesce 
before starting the flush.

Regards,
Dan

Mladen Nikitovic wrote:
    

Hi,

Flushing of both I- and D-cache seems to go fine at the moment (sets 
first then assoc). There was an error in the second loop where variable 
i was used instead of j.

However, it looks like the actions triggered by the protocol causes 
problems. INVALIDATIONS are associated with the L1_Replacement Event and 
it seems to me that a deallocation action is triggered from there. But, 
as you can see from the output below, something had gone wrong between 
sending the messages through the mandatory queue and the replacement 
event that is calling the deallocation function. From the code it 
appears as the line address has been changed, but I haven't written any 
code that changes it. Any ideas?

flushDL1caches: going through row 244
flushDL1caches: going through row 245
flushDL1caches: going through row 246
flushDL1caches: going through row 247
flushDL1caches: going through row 248
flushDL1caches: going through row 249
flushDL1caches: going through row 250
flushDL1caches: going through row 251
flushDL1caches: going through row 252
flushDL1caches: going through row 253
flushDL1caches: going through row 254
flushDL1caches: going through row 255
flushIL1caches: Dcache flush done
failed assertion 'isTagPresent(address)' at fn void 
CacheMemory<ENTRY>::deallocate(const Address&) [with ENTRY = 
L1Cache_Entry] in system/CacheMemory.h:451
failed assertion 'isTagPresent(address)' at fn void 
CacheMemory<ENTRY>::deallocate(const Address&) [with ENTRY = 
L1Cache_Entry] in system/CacheMemory.h:451
At this point you might want to attach a debug to the running and get to the
crash site; otherwise press enter to continue
PID: 18157

This is the implementation of isTagPresent:

// tests to see if an address is present in the cache
template<class ENTRY>
inline
bool CacheMemory<ENTRY>::isTagPresent(const Address& address) const
{
  assert(address == line_address(address));
  Index cacheSet = addressToCacheSet(address);
  int location = findTagInSet(cacheSet, address);
 
  if (location == -1) {
    // We didn't find the tag
    DEBUG_EXPR(CACHE_COMP, LowPrio, address);
    DEBUG_MSG(CACHE_COMP, LowPrio, "No tag match");
    return false;
  }
  DEBUG_EXPR(CACHE_COMP, LowPrio, address);
  DEBUG_MSG(CACHE_COMP, LowPrio, "found");
  return true;
}

Is there a possibility that the cache contents can change between the 
flushing (sending the messages) and the actual replacement action 
performed by the protocol? I currently cannot see how that would be 
possible but maybe you can.

/M

Dan Gibson wrote:
  
      

It looks like how I would implement the same functionality, though I don't know 
which dimension -- sets or assoc -- comes first in the m_cache member var -- 
maybe the indexes are backwards? (I haven't checked the definition)

Regards,
Dan

Mladen Nikitovic wrote:
    
        

Will do that. Thanks. Just wondered if there was anything semantically 
wrong with the code. I'm thinking about the way I've created the message 
and the way I've extracted the address from the cache. Does that seem as 
a reasonable approach?

I implemented the functions to extract the number of sets and ways and 
the address myself, there could be an error there. This is what I added 
to CacheMemory.h

template<class ENTRY>
inline
int CacheMemory<ENTRY>::getCacheNumSets()
{
  return m_cache_num_sets;
}

template<class ENTRY>
inline
int CacheMemory<ENTRY>::getCacheAssoc()
{
  return m_cache_assoc;
}

template<class ENTRY>
inline
Address CacheMemory<ENTRY>::getAddress(int i, int j)
{
  return m_cache[i][j].m_Address;
}

/M

Dan Gibson wrote:
  
      
          

This is a vector/array bounds assertion. Apparently some code in flush is 
accessing a Vector<L1Cache_Entry> with an offset too large for the specified 
size of the vector. As a first step, track down places were vectors are indexed 
in your call stack -- or better yet, attach gdb when you get the assertion and 
pop the call stack a few times to find the right spot.

Regards,
Dan

Mladen Nikitovic wrote:
    
        
            

I have reproduced the error and this is the message I get from 
Simics/GEMS when I try to do the flush:


simics> c
before flush (8023)
failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int) 
[with TYPE = L1Cache_Entry] in ../common/Vector.h:168
failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int) 
[with TYPE = L1Cache_Entry] in ../common/Vector.h:168
At this point you might want to attach a debug to the running and get to the
crash site; otherwise press enter to continue
PID: 3981
Warning: Interrupt key pressed more than once.
         Pressing it again will force Simics back to the command prompt.
         This may corrupt the running simulation.
         Try waiting for Simics to stop first.
USER INTERRUPT: Interrupt key pressed multiple times.
Returning to prompt.
simics>


Hopefully this can help someone to shed some light on this matter.

Best Regards,
Mladen

Mladen Nikitovic wrote:
  
      
          
              

Hi,

I'm trying to implement a function that flushes the L1 caches.  You can 
see from my previous posts that I have arrived at a solution that 
involves some augmentation of protocol code etc. But, the final thing is 
actually implementing the flush in the Sequencer, which was supposed to 
be done be walking the I and D-cache entries and sending invalidation 
request via the mandatory queue. I have tried to do that but the 
simulation crashes when I try call the flush at the point of shutting 
down one of the processors.

Implementation-wise, is there anything in the following function that 
should change?

Thanks.

Regards,
Mladen

void Sequencer::flushL1caches(int cpu)
{
  Time latency = SEQUENCER_TO_CONTROLLER_LATENCY;
  CacheMsg Imsg, Dmsg;
  int i,j, Iassoc, Dassoc, Isets, Dsets;

  Imsg.setType(CacheRequestType_INVALIDATE);
  Dmsg.setType(CacheRequestType_INVALIDATE);

  Isets = 
m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheNumSets();
  Dsets = 
m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheNumSets();

  Iassoc = 
m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheAssoc();
  Dassoc = 
m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheAssoc();

  for(i=0; i<Isets; i++) {
    for(j=0; i<Iassoc; j++) {
      
Imsg.setAddress(m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getAddress(i,j)); 

      m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Imsg, 
latency);
    }
  }

  for(i=0; i<Dsets; i++) {
    for(j=0; i<Dassoc; j++) {
      
Dmsg.setAddress(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getAddress(i,j)); 

      m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Dmsg, 
latency);
    }
  }
}

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

  
------------------------------------------------------------------------

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

  
------------------------------------------------------------------------

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

  
------------------------------------------------------------------------

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