Re: [Gems-users] Strange Ruby statistics

[Dan Gibson <degibson@xxxxxxxx>]

Daniele,
Let me take a crack at your questions, below.

Daniele wrote:

> Hi all. I am trying to use tester.exec with some trace-files to test
> the simulator and MOESI_CMP_NUCA  protocols. Well, as I have written
> in the forum many other times, some statistics printed by ruby seems
> to be very strange, in particular those regarding L2_hits and L2
> allocations.
>  
I'm not familiar with the codebase for the NUCA protocol... at first 
guess I would suspect that the profiling code might be to blame for the 
anomalies you have described in the past.
> So I am trying to simplify the trace-driven simulation:  in
> particular, I am trying to
>
> 1) force simulator to process all events after the last reference in trace file
>  
You will want to invoke triggerAllEvents() after the last reference is 
issued. That should complete all requests in Ruby's memory hierarchy.
> 2)
>
> Well, I have a question: may someone explain me in detail what the
> following function does?
>  
Here goes....

> void TraceRecord::issueRequest() const
> {
>  
This block of code acquires a pointer to the relevant sequencer for the 
issuing processor:
>  // Lookup sequencer pointer from system
>  AbstractChip* chip_ptr =
> g_system_ptr->getChip(m_node_num/RubyConfig::numberOfProcsPerChip());
>  assert(chip_ptr != NULL);
>  Sequencer* sequencer_ptr =
> chip_ptr->getSequencer(m_node_num%RubyConfig::numberOfProcsPerChip());
>  assert(sequencer_ptr != NULL);
>
>  CacheMsg request(m_data_address, m_type, m_pc_address,
> AccessModeType_UserMode, 0, PrefetchBit_Yes, 0, false);
>
>  
Next, the sequencer is forced to empty (in the case that the sequencer 
will have a waiting access, this code will continue to advance logical 
time until the sequencer's operations are completed. Note this may not 
clear ALL sequencers, but is fairly likely to do so).
>  // Clear out the sequencer
>  while (!sequencer_ptr->empty()) {
>    g_eventQueue_ptr->triggerEvents(g_eventQueue_ptr->getTime() + 100);
>  }
>
>  
The sequencer issues the request to the memory hierarchy.

>  sequencer_ptr->makeRequest(request);
>
>  
Again this sequencer is emptied.

>  // Clear out the sequencer
>  while (!sequencer_ptr->empty()) {
>    g_eventQueue_ptr->triggerEvents(g_eventQueue_ptr->getTime() + 100);
>  }
> }
>
> Another question:  what if I substitute the second call to
> triggerEvents with a call to triggerAllEvents() ?
>  
The second call to triggerEvents() acquiesces the sequencer 
ONLY...changing it to triggerAllEvents() would acquiesce the entire 
system. Given that time is advanced by 100 in this call to 
triggerEvents(), its relatively likely that the entire system is 
acquiesced anyway (as I recall, most latencies in the tester are quite 
small, so 100 should be much greater than the total time taken by a 
request), but triggerAllEvents() would guarantee completion of all events.
Regards,
Dan

> Sorry to be a nuisance.
> Thank you very much.
> _______________________________________________
> 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.
>
>
>