Yes, they are instantiated for each Sequencer. I also get the total hits/misses per processor. So, the results should match, right? For example, I get the following:
total_hits: 3915154 [ 1940269 1974885 ]
total_misses: 312793 [ 179164 133629 ]
---
Processor 0: Sequencer Stats
--------------------------------------------
number of hits: 5581608
number of misses: 2028197
Processor 1: Sequencer Stats
--------------------------------------------
number of hits: 5551598
number of misses: 2021201
I believe these numbers should be the same. The total_hits are profiled in transitions on load, store, and ifetch events from states other than I. The total_misses are profiled in transitions on load, store, and ifetch events from state I.
Dave
----- Original Message ----
From: Mike Marty <mikem@xxxxxxxxxxx>
To: Gems Users <gems-users@xxxxxxxxxxx>
Sent: Thursday, November 1, 2007 11:43:53 AM
Subject: Re: [Gems-users] How to identify cache hit rate in Ruby?
Are numOfHits and numOfMisses instantiated for each Sequencer, or are
they global?
The transition counts are global counts
--Mike
Dave Z. wrote:
> If I put the following code in Sequencer::makeRequest,
> and set REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH to true,
> then I should get the same number of hits/misses in
> both the Sequencer stats and cache controllers, right?
>
> if ((request.getType() == CacheRequestType_LD) ||
> (request.getType() == CacheRequestType_ST) ||
> (request.getType() == CacheRequestType_IFETCH)) {
> if (hit) numOfHits++;
> else numOfMisses++;
> }
>
> But it doesn't give me the same numbers. Is there any
> other parameter that I need to reconsider?
>
> Thanks,
>
> Dave
>
>
>
> --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
>
>
>> With REMOVE_DCACHE_FAST_PATH (or whatever the name
>> is) is set to
>> "false", the Ruby sequencer directly accesses the L1
>> cache objects to
>> determine a hit. If there is an L1 hit, then the L1
>> cache controller is
>> not invoked and you will not see "Load, Ifetch, and
>> Store" events. If
>> you want to see these events in the controllers,
>> then set the above
>> flag to "true".
>>
>> --Mike
>>
>>
>>
>> Lei Yang wrote:
>>
>>> But wait, when I compare the sum of L1D and L1I
>>>
>> misses, and the sum
>>
>>> of L1 Load, Ifetch, and Store, they are exactly
>>>
>> the same, does this
>>
>>> mean that all L1 access are misses?
>>>
>>> Lei
>>>
>>> On 11/1/07, Lei Yang <lei.d.yang@xxxxxxxxx> wrote:
>>>
>>>
>>>> Thanks Mike!
>>>>
>>>> In addition to the simics driver transaction
>>>>
>> results stats, could we
>>
>>>> also look at the chip stats? (Right below the
>>>>
>> transaction results
>>
>>>> stats, which I didn't notice before).
>>>>
>>>> Chip Stats
>>>> ----------
>>>>
>>>> --- L1Cache ---
>>>> - Event Counts -
>>>> Load 4775
>>>> Ifetch 10102
>>>> Store 25032
>>>>
>>>> This way, we'll know both L1 and L2 miss rates.
>>>>
>>>> Maybe we should consider include the results of
>>>>
>> miss/hit rates in the
>>
>>>> L1/L2 stats in the next release.
>>>>
>>>> Lei
>>>> On 11/1/07, Mike Marty <mikem@xxxxxxxxxxx> wrote:
>>>>
>>>>
>>>>> misses_per_transaction simply divides the total
>>>>>
>> misses by the total
>>
>>>>> number of transactions. This is not
>>>>>
>> transactions in Transactional
>>
>>>>> Memory. This is workload transactions (i.e., a
>>>>>
>> transaction in the
>>
>>>>> Apache web server workload).
>>>>>
>>>>> You have the L1D and L1I misses. To get the
>>>>>
>> total accesses (assuming
>>
>>>>> REMOVE_FAST_PATH... is set to false), look for
>>>>>
>> the following:
>>
>>>>> Simics Driver Transaction Results Stats
>>>>> ------------------------------------------
>>>>> Fast path: 114008467
>>>>> Request missed: 3926280
>>>>>
>>>>> The "Request missed" should equal the L1D and
>>>>>
>> L1I misses. The "Fast
>>
>>>>> path" indicates how many requests were made to
>>>>>
>> the Ruby sequencer, but
>>
>>>>> hit in the L1 caches.
>>>>>
>>>>> --Mike
>>>>>
>>>>>
>>>>>
>>>>> Lei Yang wrote:
>>>>>
>>>>>
>>>>>> Dear list,
>>>>>>
>>>>>> I'm wondering whether Ruby provides such
>>>>>>
>> statistics like cache
>>
>>>>>> hit/miss rate? For example, in the following
>>>>>>
>> stats report from Ruby:
>>
>>>>>> L1D_cache cache stats:
>>>>>> L1D_cache_total_misses: 29807
>>>>>> L1D_cache_total_demand_misses: 29807
>>>>>> L1D_cache_total_prefetches: 0
>>>>>> L1D_cache_total_sw_prefetches: 0
>>>>>> L1D_cache_total_hw_prefetches: 0
>>>>>> L1D_cache_misses_per_transaction: 29807
>>>>>> L1D_cache_misses_per_instruction: 0.000143247
>>>>>> L1D_cache_instructions_per_misses: 6980.94
>>>>>>
>>>>>> L1D_cache_request_type_LD: 16.0197%
>>>>>> L1D_cache_request_type_ST: 82.7557%
>>>>>> L1D_cache_request_type_ATOMIC: 1.22454%
>>>>>>
>>>>>> L1D_cache_access_mode_type_SupervisorMode:
>>>>>>
>> 6933 23.2596%
>>
>>>>>> L1D_cache_access_mode_type_UserMode: 22874
>>>>>>
>> 76.7404%
>>
>>>>>> L1D_cache_request_size: [binsize: log2 max:
>>>>>>
>> 64 count: 29807 average:
>>
>>>>>> 4.90469 | standard deviation: 4.44371 | 0 642
>>>>>>
>> 88 23854 5077 0 0 146 ]
>>
>>>>>> We know the total L1D cache misses, and the
>>>>>>
>> misses_per_instruction.
>>
>>>>>> But do we know the total number of cache
>>>>>>
>> acesses, and thus the
>>
>>>>>> hit/miss rate? Also, what does
>>>>>>
>> misses_per_transaction mean?
>>
>>>>>> Thank you in advance!
>>>>>> Lei
>>>>>> _______________________________________________
>>>>>> 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.
>>
>>>
>>>
>> _______________________________________________
>> 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.
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> 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.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}