Corey,
We still need to settle on the user interface to extract default
information (and maybe aliases information).
Here is what I have today:
typedef struct {
const char *name;
const char *desc;
const char *alias;
pfm_pmu_t pmu;
int idx;
int nattrs;
int size;
uint64_t code;
struct {
int is_alias:1;
int reserved:31;
};
uint64_t reserved[9];
} pfm_event_info_t;
typedef struct {
const char *name;
const char *desc;
const char *alias;
pfm_attr_t type;
struct {
int is_dfl:1; /* is default */
int is_alias:1;
int reserved:30;
};
int idx;
int size;
uint64_t code;
union {
uint64_t dfl_val64;
const char *dfl_str;
int dfl_bool;
int dfl_int;
};
uint64_t reserved1[6];
} pfm_event_attr_info_t;
int pfm_get_event_info(int idx, pfm_event_info_t *info);
int pfm_get_event_attr_info(int idx, int attr_idx, pfm_event_attr_info_t *info);
Notice the new is_alias and the alias string which is valid only if is_alias
is set. it contains the event string describing how the alias build on the
original event, e.g., with hardwired modifiers.
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.
>
> 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
>
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
