Corey,
On Fri, Dec 11, 2009 at 11:39 PM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
> Hi Stephane,
>> 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.
>
Yes.
> I like this API. This should make tool writing very easy.
>
Yes, I think it is simpler. Yet we still need a way to extract
default information. I used one in showevtinfo with the data
structure we talked about.
>> 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.
>
For now, dfl_plm cannot be zero, i.e., need to provide a default priv
level. You have
no guarantee the user passed something. if nothing is passed in the event string
and dfl_plm=0, then nothing is going to be measured. The way it is now
will catch
any stupid mistakes. OTOH, it might be useful to allow no priv level
set, but I can't
think of an example right now. Note that dfl_plm may be ignored once
there are events
which do not need it.
To answer the underlying question, anything the user passes in the event string
has higher priority than dfl_plm. I can have dfl_plm = PLM3 (u=1) and an event
string with k=1, if which case the event will measure at the kernel only.
>> Thus the tool, may now chose to diplay the full name instead of just
>> the specified name.
>
> Very nice.
>
Yes, and this week-end I added the missing piece to this puzzle having to do
with hardwired modifiers. Here is an example on Core 2:
{ .name = "RS_UOPS_DISPATCHED_NONE",
.code = 0xa0 | (1 << 23) | (1 << 24),
.cntmsk = 0x3,
.modmsk = _INTEL_X86_ATTR_U|_INTEL_X86_ATTR_K,
.flags = INTEL_X86_ALIAS,
.alias = "RS_UOPS_DISPATCHED",
.desc = "Number of of cycles in which no micro-ops is
dispatched for execution",
},
This is an event that is an alias to another event but it has some
modifiers hardcoded.
(i=invert, c=counter-mask). So first you noticed that are not part of
the modmsk (which
is the attrmsk we talked about). Second, you have the INTEL_X86_ALIAS
which indicates
this is an alias with the actual event pointed to by .alias. In this
case, the fstr coming out
is:
$ perf_examples/task -e rs_uops_dispatched_none date
[0x1d100a0 event_sel=0xa0 umask=0x0 os=0 usr=1 en=1 int=1 inv=1 edge=0
cnt_mask=1]
PERF[type=4 val=0x1d100a0 e_u=0 e_k=1 e_hv=1]
RS_UOPS_DISPATCHED:k=0:u=1:e=0:i=1:c=1
FQSTR=RS_UOPS_DISPATCHED:k=0:u=1:e=0:i=1:c=1
>>
>> 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.
>
Given what I just described above, OPS_ISSUED:STALLED_CYCLES would now
come out as fstr=UOPS_ISSUED:ANY:c=1:i=1 which makes more sense. Because
now you have both the logical event string (what you pass) and the actual event
string. The tool has both and can decide which one to use.
As for your question, the way the code is, it would not be legit, You
cannot set a
hardwired modifier, even if it is to the same value.
> 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.
------------------------------------------------------------------------------
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
