| My code wouldn't be useful for you specifically, as I've made quite a number of changes to support some other things we're doing, and therefore it wouldn't fit into GEMs, and has far more variables than you'd need.
However, the basic idea is pretty simple. In a header file declare a struct (or a class that's friends with pseq or whatever). Call it CtxStat for instance typedef struct CtxStat_ { uint64 Insts;
uint64 Cycles;
uint64 StartInst;
uint64 StartCycle
} CtxStat;
Then in pseq.h add a private variable to keep track of per context information (my code currently doesn't work with SMT enabled, but a few modifications would fix this). For instance: map<int, CtxStat> g_CtxStats; (you could change this to an array of maps that are created at initialization time to support the SMT extensions.
Then in pseq.C you'll want to edit the contextSwitch(context_id_t new_context,unsigned int proc) function (I want to say there's a bug somewhere in there in how they kept track of context information, but I could be wrong, I remember fixing it, and think it may have been an SMT related bug that didn't effect execution, but meant that often m_primarty_ctx[proc] wasn't valid... Luke might remember, or I might be able to dig it out of an old email somewhere).
In this function you just want to first update the old context information (the one corresponding to m_primary_ctx[proc]) counting the number of instructions and cycles to add to the map class. So the number of instructions is just m_stat_committed[proc]-g_CtxStats[m_primary_ctx[proc]].StartInst. Similarly, you calculate the number of cycles to as as m_local_cycles - g_CtxStats[ . . .
Then the only tricks you'll need are adding code to output the stats. In mine I just output them at the end of the pseq::printStats function. I just iterate over the map and print out the stats for each context. Of course later you'd want to aggregate the stats across all processors. Personally, I just handle this with a perl script that does the aggregation.
Hope this helps, Phil
On Jun 2, 2009, at 7:45 PM, Carole-Jean Wu wrote: Hello Phil,
Would you be able to share your modification of pseq that keeps track of per context information?
Thanks!
Carole
On Tue, Jun 2, 2009 at 12:21 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote: If you're trying to calculate some of these stats for a multiprocessor system with single threaded applications running, you really would want to keep track on instructions committed per context ID. The OS (at least in Linux) will use context 0, whereas applications will have different context IDs. What you probably don't want to do is count cycles/instructions where a CPU isn't doing useful work. I have a somewhat modified version of pseq that keeps track of per context information, but it's also tailored to other needs. In general, I've found it useful, as you can also track whether applications have migrated across cpu's in multicore workloads.
Phil On Jun 2, 2009, at 12:58 PM, David Bonavila wrote:
Hi.
I have added the following lines to the pseq.C file:
/*------------------------------------------------------------------------*/
/* Variable declarations */
/*------------------------------------------------------------------------*/
int iPriv[2] = { 0, 0 }; // I am simulating a 2-core processor
int iUser[2] = { 0, 0 };
if (d_instr) {
last_mode = d_instr->getPrivilegeMode(); // this line already existed
if (last_mode) iPriv[proc]++; // I have added these two lines
else iUser[proc]++;
}
out_info(" %-50.50s %10llu\n", "PRIVILEGED INSTRUCTIONS:", iPriv[k]);
out_info(" %-50.50s %10llu\n", "USER_MODE INSTRUCTIONS:", iUser[k]);
I have simulated 1 Million instructions with Opal, and the Opal output file has this:
[0] PRIVILEGED INSTRUCTIONS: 219278
[0] USER_MODE INSTRUCTIONS: 175210
[1] PRIVILEGED INSTRUCTIONS: 219278
[1] USER_MODE INSTRUCTIONS: 175210
The two processors have executed the same number of privileged instructions??
And the total instructions (Privileged + User) is different from 1M (I have changed Opal so the number of instructions passed to the opal0.sim-step command is the TOTAL number of instructions executed between all processors, not just CPU0).
I am simulating a workload which runs only 1 thread.
Is all this right??
Am I doing something wrong??
Thanks!!
_______________________________________________
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.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}