Corey,
On Wed, Dec 9, 2009 at 11:45 PM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
I have succesfully added the ngrp/grpid (grouping) support to all
X86 processors. I also added a way to mark unit masks as defaults.
Things like as follows:
{ .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,
.grpid = 0,
},
{ .uname = "STALLED_CYCLES",
.udesc = "Cycles stalled no issued uops",
.ucode = 0x01 | (1<<16) | (1<<15), /*
c=1, i=1 */
.uflags = 0,
.grpid = 0,
},
{ .uname = "FUSED",
.udesc = "Fused Uops issued",
.ucode = 0x02,
.uflags = 0,
.grpid = 0,
},
},
.numasks = 3
},
If the user passes UOPS_ISSUED, then UOPS_ISSUED:ANY is used.
From this example, there are some issues that still need to be resolved and
they go back to our earlier discussion. I think it would be useful for
the tool to
print UOPS_ISSUED:ANY when it displays the results. That way the user
would know exactly what was measured.
Remember that at the user level, tools only see event strings or opaque
event and attribute identifiers. So how would the tool go from UOPS_ISSUED
to UOPS_ISSUED:ANY?
The library can return that ANY is the default. But the tool needs to know that
the default was actually used by the library because the user did not
specify any
unit mask. In this particular example, it is fairly simple, the tool
can simply look for ':'.
But take a more complicated example, with multiple unit masks groups.
{ .name = "EVENTA",
.ngrp = 2,
.umasks = {
{ .name = "A", .grp = 0, .flags = IS_DFL },
{ .name = "B", .grp = 0 },
{ .name = "C", .grp = 0 },
{ .name = "D", .grp = 1 },
{ .name = "E", .grp = 1 },
{ .name = "F", .grp = 1 , flags = IS_DFL },
{ .name = "G", .grp = 1 },
}
If the user passes EVENTA:B, then the library sets up EVENTA:B:F.
The tool can query the library for defaults and it will get A, F. Given
the tool does not know anything about grouping, it could not simply
parse the string looking for missing unit mask.
I believe the conversion from requested -> actual can only be done
by the library. It must be part of the perf_events encoding call or
any encoding call. Thus the call would have to look as follows:
int pfm_get_perf_event_encoding(const char *str, char **act_evt,
struct perf_event_attr *hw, int *idx);
Passing "UOPS_ISSUED"
would yield
act_evt="UOPS_ISSUED:ANY:u=1:k=0:i=0:c=0:e=0"
In other words, the fully specified event string.
>> I think we could do macros using modifiers. Using the example above,
>> imagine
>> I want to create a macro foo which means i=1:eth=2. Then, I could do:
>>>>
>>>> attrs[]={
>>>> 0 { .name = "e", .type = BOOL },
>>>> 1 { .name = "i", type = BOOL },
>>>> 2 { .name = "eth", .type = INTEGER},
>>
>> 3 { .name = "foo", .type= BOOL }
>>>>
>>>> };
>>
>> Then in the event table do:
>> { .name = "EVT1",
>> .code = 0xa0,
>> .mods = "foo",
>> .ngrp = 0,
>> .attrmsk = 0x1,
>> .numasks = 0,
>> }
>>
>> Modifiers are model specific, thus the PMU code would know how to
>> translate foo into i=1:eth=2.
>
> So there would be ad hoc pfmlib code to translate "foo" to "i=1:eth=2", at
> worst on a per-event basis? I was hoping to make that translation available
> in the table for use by pfmlib, so that the pfmlib code wouldn't have to
> know anything except how to read the data in the table. If it were in the
> table, tools could display it without having to understand the pfmlib logic.
>
But what if the description of foo is:
attrs[]={
0 { .name = "e", .type = BOOL },
1 { .name = "i", type = BOOL },
2 { .name = "eth", .type = INTEGER},
3 { .name = "foo", .type= BOOL , .desc="alias for i=1:eth=2" }
The tool would get the description of foo transparently.
>
> You also removed foo as specifiable, right?
Yes.
> So .attrmsk specifies the modifiers that the user can supply, for example
> in the above case,
> "EVT1:e=0"
> would be legal and meaningful, but "EVT1:foo" would not be okay.
>
Yes, though there are some issues with this approach especially when you
have unit mask with hardwired modifiers. Take the UOPS_ISSUED example
above. You would have to drop i, c from the list of available modifier ONLY
when STALLED_CYCLES is passed. There is a chicken and egg problem
there. You don't have it with event with no unit masks like on your CPU.
I think in this case, you have no choice but do fail, you cannot a priori
remove those modifiers.
> Looking at the example, it appears that .mods is the way of specifying
> hardwired modifiers and umasks? I'm not quite clear why .mods is a string
> rather than just a another mask which designates which attributes are
> hardwired. I think I need to see some more examples of why this is a string.
>
I used strings, because if it were a bitmasks, how would you pass the values
of the modifiers. Not all modifiers are booleans. The advantage of the string
is that it is extensible and can contain any kind of information. Also the tools
only deal with strings and opaque event/attr identifiers. They do not know about
bits like those in .attrmsk.
> If the user cannot specify foo in this example, why do we even need to have
> a name for this attribute? Can't the ad hoc code just determine the
> modifier values without having this attribute present; in other words, I
> don't see the purpose for this if we just end up hard-coding the hard-wired
> values.
>
I don't quite understand your point here. What do you call the 'ad hoc' code?
Are you saying the library could poke at the event code to figure out what
is hardcoded and what is not, i.e., no need to duplicate this info
into a string?
> When I say hard-wired, I'm referring to events which have attributes which
> must be set in a certain way to give correct counter results.
>
That's a different problem. Now you're talking about providing a range
of valid values. Do you want that reported that to the user?
------------------------------------------------------------------------------
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
