Thanks Dan.
I'm not sure what you mean by the L1s are not separate entities in all
the protocols.
I notice that for the MOESI_CMP protocol, the L1Cache controller calls
profile_miss(...) from the Ruby_Slicc interface which in turn calls
addSecondaryStatSample(...) which increments the number of misses in the
L2 cache.
The L2Cache controller calls profile_L2Cache_miss(...) which in turn
calls addSecondaryStatSample.
I'm not too clear on the difference in the details between the different
protocols, but it seems odd that the L1 cache controller's profiling
function eventually calls addSecondaryStatSample(...). This is not the
case in the MOSI_SMP protocol though.
Ranjith
Dan Gibson wrote:
Many of the protocols do not actually profile the L1s.
In fact, the L1s are not separate entities in the all the protocols...
so the point at which L1 accesses are profiled varies from protocol to
protocol, if indeed they are profiled at all.
It should be relatively straightforward to add L1 profiling. If "fast
path hits" are ON, (see rubyconfig.defaults), then you can add profiling
code to Sequencer.C. Otherwise, you can use the L1 controller's SLICC code.
Regards,
Dan Gibson
Ranjith Subramanian wrote:
Hello,
I have a question about how cache misses are profiled in ruby. I start
simics, load a checkpoint which is essentially the prompt after a linux
boots up, load ruby and continue simulating for a few seconds and dump
ruby stats. I see that the L1 instruction and data caches aren't
accessed at all but the L2 cache is. All the misses reported for the L2
cache are demand misses. I'm not sure what I'm missing here.
Ranjith
_______________________________________________
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.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}