stephane eranian wrote: > Corey, > > Ok, so I tried what we talked about on a couple of > examples (some made up). And now here is what > I get: > > $ task -euops_issued:any,l2_ifetch:mesi date > > [0x513f0e event_sel=0xe umask=0x3f os=0 usr=1 en=1 int=1 inv=0 edge=0 > cnt_mask=0] UOPS_ISSUED > FSTR=UOPS_ISSUED2:PORT0:PORT1:PORT2:PORT3:PORT4:PORT5:k=0:u=1:e=0:i=0:c=0 > > [0x514f28 event_sel=0x28 umask=0x4f os=0 usr=1 en=1 int=1 inv=0 edge=0 > cnt_mask=0] L2_IFETCH > FSTR=L2_IFETCH:SELF:I_STATE:S_STATE:E_STATE:M_STATE:k=0:u=1:e=0:i=0:c=0 > > That looks like what you suggested. This is all handled in X86 code. > Hard to make it more specific than that!
Yes, this is great :-) I can't see needing anything other than this right now. Perhaps in an initial port of an arch to libpfm4, fstr would just be a copy of str (or perhaps NULL to specify unimplemented). Later the reverse translation can be added. One question about the above example: I see usr=1... I assume the "task" program is passing in plm=<value for user mode> ? About the event aliases in the previous posting, wouldn't it be the case that having such aliases could cause an explosion in the number of events (mostly aliases) in the event table, since many events might need such variants? -- Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cjash...@us.ibm.com ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
