Hi Stephane,
stephane eranian wrote:
> Corey,
>
> I spent some time today experimenting with what I described yesterday
> and in particular the fully qualified event string support. I got that working
> on X86. There are still a few things to patch up but looks promising.
>
> I have also added the defaul priv level support we talked about some
> time ago.
>
> Now the prototype for perf_events looks as follows:
>
> pfm_get_perf_event_encoding(const char *str, int dfl_plm, struct
> perf_event_attr *hw, char **fstr, int *idx);
>
> Here is an example on Core 2.
>
> Name : RS_UOPS_DISPATCHED_CYCLES
> Desc : Cycles micro-ops dispatched for execution
> Code : 0xa1
> Umask-00 : 0x01 : [PORT_0] : on port 0
> Umask-01 : 0x02 : [PORT_1] : on port 1
> Umask-02 : 0x04 : [PORT_2] : on port 2
> Umask-03 : 0x08 : [PORT_3] : on port 3
> Umask-04 : 0x10 : [PORT_4] : on port 4
> Umask-05 : 0x20 : [PORT_5] : on port 5
> Umask-06 : 0x3f : [ANY] : on any port (DEFAULT)
> Modif-00 : 0x00 : [u] : monitor at priv level 1, 2, 3 (boolean)
> Modif-01 : 0x01 : [k] : monitor at priv level 0 (boolean)
> Modif-02 : 0x02 : [i] : invert (boolean)
> Modif-03 : 0x03 : [e] : edge level (boolean)
> Modif-04 : 0x04 : [c] : counter-mask in range [0-255] (integer)
>
>
> % task -eRS_UOPS_DISPATCHED_CYCLES date
> [0x513fa1 event_sel=0xa1 umask=0x3f os=0 usr=1 en=1 int=1 inv=0 edge=0
> cnt_mask=0] RS_UOPS_DISPATCHED_CYCLES:ANY:u=1:k=0:i=0:e=0:c=0
> PERF[type=4 val=0x513fa1 e_u=0 e_k=1 e_hv=1]
>
> FQSTR=RS_UOPS_DISPATCHED_CYCLES:ANY:u=1:k=0:i=0:e=0:c=0
>
I assume FQSTR here is the "fstr" parameter in the prototype.
I like this API. This should make tool writing very easy.
> Few things to note in this output:
> - notice that showevtinfo print (DEFAULT) now
> - the library build the fully qualified event string
> - ANY was default,
> - dfl_plm = PFM_PLM3 (u)
Could the user have achieved the same thing by specifying dfl_plm = 0, and then
add ":u=1" to the event string? I would assume that would be legal.
> - no modifier was set by user
>
> Thus the tool, may now chose to diplay the full name instead of just
> the specified name.
Very nice.
>
> Now, I need to deal with events which have hardcoded modifers. On x86,
> those are provided
> for convience, thus they are always a clone of an existing event or unit mask.
> Let's look at an example:
>
> { .name = "UOPS_ISSUED",
> .desc = "Micro-ops issued",
> .modmsk = INTEL_V3_ATTRS,
> .cntmsk = 0xf,
> .code = 0x0E,
> .flags = INTEL_X86_UMASK_NCOMBO,
> .ngrp = 1,
> .umasks = {
> { .uname = "ANY",
> .udesc = "Uops issued",
> .ucode = 0x01,
> .uflags = INTEL_X86_DFL_UMASK,
> },
> { .uname = "STALLED_CYCLES",
> .udesc = "Cycles stalled no issued uops",
> .ucode = 0x01 | (1<<16) | (1<<15), /*
> counter-mask=1, inv=1 */
> .uflags = 0,
> }
> ...
> }
>
> UOPS_ISSUED:STALLED_CYCLES is equivalent to
> UOPS_ISSUED:ANY:c=1:i=1
>
> The question is what do you print here?
Sorry, I'm a little confused here. Do you mean hard-wired or hard-coded? It
looks like a ucode of 0x1 is required (needs to be hard-wired), but there are
also a couple of optional bits which can be turned on, and you've given a name
to one such optional encoding. Would it be legit also to specify
"UOPS_ISSUED:ANY:i=1" or "UOPS_ISSUED:ANY:c=1"? I would assume so.
As for the printing issue, let's say someone specifies
"UOPS_ISSUED:ANY:c=1:i=1", the question is, is the fully qualified name
"UOPS_ISSUED:STALLED_CYCLES" or is it "UOPS_ISSUED:ANY:c=1:i=1" ? Also, if
they
specify "UOPS_ISSUED:STALLED_CYCLES", what would be the proper fully qualified
name? Hmm. Either way has its downsides... one way is more compact and
perhaps
more descriptive, and the other way is completely transparent, but perhaps
harder to read and maybe too verbose.
Maybe there should be a "verbose" option that when set would spell out all of
the options, and when not set, would attempt to compact the settings into known
umasks + individual modifiers. That might be ideal, but given the structure
above, I think it might be hard to implement without some changes. We'd need
to
find some way of calculating whether a umask's ucode is a subset of the
settings
specified by the event string.
- Corey
------------------------------------------------------------------------------
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
