Re: [Gems-users] flushing L1D cache

[Dan Gibson <degibson@xxxxxxxx>]

Basically, one way or another you've made SimicsProcessor think there is another request coming from Simics -- thats why lingering request isn't set. Either detect when you're issuing cache-clearing accesses (and DON'T set m_lingering_request in those cases) or detect when m_lingering_request is set out-of-range and fix it.

Mladen Nikitovic wrote:

by "passing through to the Sequencer", do you mean an early return in 
the hitCallback function?

This is a suggestion for the first few lines in hitCallback function.

void SimicsProcessor::hitCallback(SubBlock& data) {
  DEBUG_MSG(SEQUENCER_COMP, MedPrio, "hitCallback");
  DEBUG_EXPR(SEQUENCER_COMP, MedPrio, m_proc);
  DEBUG_EXPR(SEQUENCER_COMP, MedPrio, data.getAddress());
  DEBUG_EXPR(SEQUENCER_COMP, MedPrio, data.getSize());

*  if(data.getAddress().getAddress() < 0x100000000ll && 
data.getAddress().getAddress() >= RubyConfig::memorySizeBytes()/2)
    return;
*....

Basically, I'm checking if the address is within the address space where 
I issue my "flushing" requests. I noticed that requests above 
0x100000000ll belong to the transaction log, so I had to add that condition.

Is this what you had in mind?

/M

Dan Gibson wrote:
  

The 'lingering' request is SimicsProcessor's way if hiding a particular 
peculiarity of the Simics interface:
When Simics sends a request to Ruby for timing information, it expects a 
stall time in return. Ruby provides this -- 2 billion cycles in most 
cases. Thats OK, since Ruby is going to eventually explicilty unstall 
simics with a call to SIMICS_stall_cycle(). However, when Simics is 
explicitly unstalled, it re-issues the memory request to Ruby. (In 
effect, it asks it's cache model AGAIN if the block is there or not). 
This second request is intercepted at SimicsProcessor, identified as the 
lingering request, and the rest of Ruby never sees it.

You should modify SimicsProcessor to allow your writeback callbacks to 
pass through to the sequencer. Either add a flag (last_flushing_addr ?) 
or maybe just check if the address is sufficiently large...

Regards,
Dan

Mladen Nikitovic wrote:
  
    

Hi,

I'm encountering some problems when flushing the L1 data cache of a 
processor. I have already notified the target operating system that the 
processor is offline, so there is no problems regarding that. The 
processor does not execute any real instructions after that.

The approach is to simply walk the cache, detect the entries that are 
dirty and by issuing a write operation to that same entry (but with an 
address that would not conflict any other requests, using addresses 
beyond the physical memory size, yes I do lie to ruby about the size :) 
one would  to force the entry out to the L2.

I did the following in Sequencer.C (where the flush is implemented).

First I addressed the mandatory queue explicitly of that processor that 
is being shut down. I enqueued requests of type CacheRequestType_ST with 
addresses that would force the cache to push out the dirty entries (the 
physical memory size is 256MB but I use address space 256 - 512 MB to 
request data addresses that will not be used in reality, they are only 
used for flushing).

However, using this approach i got the following assertion:

Sequencer: flushIL1caches: Dcache flush done
failed assertion 'm_writeRequestTable_ptr->exist(line_address(address))' 
at fn void Sequencer::writeCallback(const Address&, DataBlock&, Gener 
icMachineType, PrefetchBit) in system/Sequencer.C:403
failed assertion 'm_writeRequestTable_ptr->exist(line_address(address))' 
at fn void Sequencer::writeCallback(const Address&, DataBlock&, Gener 
icMachineType, PrefetchBit) in system/Sequencer.C:403
At this point you might want to attach a debug to the running and get to the
crash site; otherwise press enter to continue

This assertion led me to the conclusion that I probably need to make a 
call to makeRequest in order to force the request to exist in the 
writeRequestTable.

So, the "flush" is now done the follwing way:

  for(i=0; i<Dsets; i++) {
    for(j=0; j<Dassoc; j++) {
      if(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[cpu]->getDirty(i,j)) {
        
m_chip_ptr->getSequencer(cpu)->makeRequest(CacheMsg(Address(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[cpu]->getAddress(i,j) 
+
                                    (RubyConfig::memorySizeBytes()/2)),
                                CacheRequestType_ST,
                                Address(0),
                                AccessModeType_SupervisorMode,
                                4,
                                PrefetchBit_No,
                                0,
                                false));
      }
    }
  }

Using this approach I get the following assertion instead:

Sequencer: flushIL1caches: Dcache flush done
failed assertion 'm_lingering_request_address != Address(0-1)' at fn 
void SimicsProcessor::hitCallback(SubBlock&) in simics/SimicsProcessor.C:202
failed assertion 'm_lingering_request_address != Address(0-1)' at fn 
void SimicsProcessor::hitCallback(SubBlock&) in simics/SimicsProcessor.C:202
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: 19536

There is something about a "lingering_request" that is supposed to be 
equal to Address(0-1), but I don't understand what might be wrong with 
my request. Am I missing something regarding the parameters to my call 
to MakeRequest?

Hope you can help me.

/Mladen


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