Re: [Gems-users] profiling L1 and stat inconsistency

["Mladen Nikitovic" <mladen@xxxxxxxxxxx>]

Hi,

Dan, thank you for the response. My follow-up-question is: If I need to use
the sequencer in order to get correct statistics, which of the three
functions of makeRequest, doRequest, or issueRequest is most suitable for my
intention? all of them provide different information, however a cache
hit/miss determined in doRequest, so my suggestion is there, but I am not
sure..

I see a problem with these functions and that is that the memory transaction
message has been converted to a cache message by the time these functions
are used (this was one of the reasons I used the profiler functions which
has NodeID as a parameter), so information about which processor (s.ini_ptr)
made the request is lost. Since I want to distinguish requests on processor
basis, this becomes an obsticle. Perhaps you have any suggestions..

Regards,
Mladen

-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
On Behalf Of Dan Gibson
Sent: den 7 december 2006 15:13
To: Gems Users
Subject: Re: [Gems-users] profiling L1 and stat inconsistency


Mladen,

You're observing an artifact of the Ruby/Simics interface. Simics 
presents Ruby with each memory request at least twice, often more than 
twice (especially for atomics and certain race conditions). Simics is 
designed to stall a memory request until it is satisfied, then re-verify 
with the timing model that it is OK to proceed. SimicsProcessor filters 
the replay requests, and since SimicsDriver sits between SimicsProcessor 
and Simics itself, you're profiling simulation artifacts.

Again, I recommend the sequencer for L1 profiling =) .

Regards,
Dan Gibson

Mladen Nikitovic wrote:

>Hi,
>
>Two questions:
>
>Previously, I recieved a tip that I could profile L1 cache 
>accesses/misses on a per processor basis by adding profiling code to 
>the Sequencer.
>
>I found that one could extend the integer counters (in Profiler 
>functions addL1DStatSample and addL1IStatSample) into vectors and 
>distinguish the L1 accesses there. To distinguish total number of 
>(instruction and data) L1 accesses on a per processor basis, I used the 
>same vector-solution in the SimicsDriver function 
>recordTransactionStats. Does this approach sound reasonable to you? I'm 
>afraid that I could miss some stats, which leads me to my next 
>question...
>
>I discovered a inconsistency in my stats that I could not understand. 
>In the Simics Driver Transaction Stats I found that the sum of Insn and 
>Data
>(17,285,301) does not match the number of Fast path accesses in the Simics
>Driver Transaction Result Stats. Is it because there are requests that does
>not go through the caches or is it due to some other reason? Any ideas?
>
>My Simics Driver Stats looks like this:
>
>Simics Driver Transaction Stats
>----------------------------------
>Insn requests: 13869063 [ 3262320 3024289 3460288 4122166 ] Data 
>requests: 3416238 [ 798931 748882 861595 1006830 ] Memory mapped IO 
>register accesses: 0 Device initiated accesses: 0
>Other initiated accesses: 0
>Atomic load accesses: 174
>Exceptions: 295
>Non stallable accesses: 651
>Prefetches: 0
>Cache Flush: 0
>
>Requests of asi 0x4: 44120
>Requests of asi 0x10: 33
>Requests of asi 0x11: 19
>Requests of asi 0x14: 4062
>Requests of asi 0x24: 26
>Requests of asi 0x34: 148
>Requests of asi 0x80: 17236893
>
>Simics Driver Transaction Results Stats
>------------------------------------------
>Fast path: 17279244
>Request missed: 5406
>Sequencer not ready: 0
>Duplicate instruction fetches: 2427
>Hit return: 2746
>Atomic last accesses: 231
>
>
>Best Regards,
>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.