Hi all, I would suggest to skip the hackish solution and go for a solution that will eventually allow you to expose these stats to the OS. Have a look at src/arm/pmu.cc,hh for how the performance counter are created as probes. In essence the probe infrastructure would let you monitor and probe packets, stats, instructions etc based on the creation of probe points. Your cache probe could then be given pointers to the L1s and L2 in the Python code.
Andreas On 25/03/2015 02:22, "Gokul Subramanian Ravi" <[email protected]> wrote: >Nimish Girdhar <nimishg <at> tamu.edu> writes: > >> >> >> Thanks for your reply. >> I am looking to insert my counters in the gem5 source code so that I >>can >look at them and do some calculations while the benchmark is running on >the >gem5 simulated hardware..... >> I don't get the part of probe infrastructure....can you explain it a >>bit >more... >> Thanks, >> On Mar 24, 2015 3:00 AM, "Andreas Hansson" <Andreas.Hansson <at> >>arm.com> >wrote: >> >> >> >> >> Hi Nimish, >> >> When you say “count at runtime”, do you mean 1) in the software on the >guest, or 2) just in a simulated hardware module? For #1 I would suggest >to >add them as PMU counters, and #2 you can use the probe infrastructure and >a >custom probe listener. >> >> Andreas >> >> >> >> From: Nimish Girdhar <nimishg <at> tamu.edu>Reply-To: gem5 users >>mailing >list <gem5-users <at> gem5.org>Date: Tuesday, 24 March 2015 03:31To: gem5 >users mailing list <gem5-users <at> gem5.org>Subject: [gem5-users] >Counting >cache misses runtime >> >> >> Hello all, >> >> I am working with ARM full system mode with classic memory model and I >want to count the icache, dcache, L2 misses at runtime. I am not able to >find where in the source code are these counters resident. I tried >tracing >back from the regstats in the src/mem/base.cc >> file but in vain. >> >> Has anybody done it before? >> >> Thanks, >> > >Hi Nimish, > >My understanding is that you want your CPU side to be able to access >stats >from I/D/L2 caches for which you want to access the cache pointers. > >Below is my implementation which a) May be a bit specific to my own arch >b) >Is a bit hacky and not a clean implementation. > >You will notice that your cpu defines an icacheport and a dcacheport >(master ports) to send/receive requests/responses from the 1st level >caches. > >To access icache (and dcache) I did the following - > >In my src/mem/ports.cc, > >I created a function to get a * slave-port's owner's pointer * - > >MemObject* >MasterPort::GetSlaveOwner() >{ > MemObject *a = &_slavePort->owner; > return a; >} > >Then in my cpu.cc, since I know I am accessing the cache pointer, I >typecast this MemObject as a CacheObject and access IC data - > >Cache<LRU>* pointer_ic = (Cache<LRU>*)cpu->getInstPort().GetSlaveOwner(); > >uint64_t ic_miss_data = pointer_ic->overallMisses.total() > >The above works for DC as well. > >For L2 cache, it is a bit more complicated due to the presence of a bus >between the L1 and L2 cache (at least in my case). > >So I do the following - > >Using the Icache pointer that I just obtained above, I access the memory >side port of the Icache (pointer_ic->memSidePort). > >The slave-port corresponding to this memsideport is on the coherent bus. >So >I use the same GetSlaveOwner function defined above, to access the slave- >port and then its owner. This needs to be type-casted as a coherent bus >(in >my case). > >CoherentBus* pointer_bus = (CoherentBus*)pointer_ic->memSidePort- >>GetSlaveOwner(); > >Now I have the pointer to the Coherent Bus. With this I access the master >port for the bus (which is where my L2 is connected) and get its slave- >port's owner which is the L2. > >Cache<LRU>* pointer_l2 = (Cache<LRU>*) pointer_bus->masterPorts[0]- >>GetSlaveOwner(); > >uint64_t l2_miss_data = pointer_l2->overallMisses.total() > >If you would need to access the l3, you can follow the same analogy above >and go one step further etc. > >Again, based on how your caches are attached to the buses, this >implementation may change, but hopefully the above will point you in the >right direction. > >Best, >Gokul Subramanian Ravi > >University of Wisconsin - Madison > > >_______________________________________________ >gem5-users mailing list >[email protected] >http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
