Thanks for the reply, Stephane,
stephane eranian wrote:
> 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.
So it's a true default, then, not just an initial value. Thanks for that
clarification.
>
>>> 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
I'm guessing the "... | (1 << 23) | (1 << 24)" are the invert and counter mask
bits?
Does this mean you have to have code that does a reverse translation from the
code value to attribute strings?
>
>>> 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.
>
Oh, I get it now. ANY is 0x3f...all PORT_* bits set. Somehow I was thinking
it
was a 0x0 value, which in retrospect may not make much sense for a umask
anyway,
since 0 is the default value.
With that in mind, let's say I specify:
UOPS_ISSUED:PORT_0:PORT_1:PORT_2:PORT_3:PORT_4:PORT_5:c=1:i=1
would fqstr come back as
UOPS_ISSUED:ANY:c=1:i=1 ?
If so, is there a way to accomplish this reverse translation in a generic,
table-driven way, or must it be done per arch? I'm thinking it's the latter,
because the architectures are so different.
>> 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
