On Tue, Dec 15, 2009 at 12:09 AM, Corey Ashford <cjash...@linux.vnet.ibm.com> wrote: > > > 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.
Yes, that would be fine. > > One question about the above example: I see usr=1... I assume the "task" > program is passing in plm=<value for user mode> ? > That is the effect of dfl_plm. > 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? > Based on the X86 situation, I don't think so. The event table contains primarily a clone of the documented event table as publish by the HW vendors. In the case of Intel, some events are clearly documented as requiring some modifiers to be set to specific values. For other events, it is suggested that if certain modifiers are turned on, then a different metric can be measured. Finally they are common metrics, i.e., events with modifiers what are used very frequently and therefore justify adding their alias to the table (as opposed to having to type the whole thing each time). So overall, I don't think this would contribute to the explosion in the number of entries in the table. Hopefully, the situation is similar on Power and your new CPU. > -- > 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
