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

[Dan Gibson <degibson@xxxxxxxx>]

I would suggest makeRequest for *accesses* and possibly doRequest for non-L1 hits.

There is one sequencer per processor... so the information is not "lost", it is merely placed in a member variable of the sequencer object. I do not recall its name, but it should be easy to find by having a look at Sequencer.h.

Regards,
Dan

Mladen Nikitovic wrote:

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.



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