stephane eranian wrote:
> Corey,
>
> On Wed, Dec 9, 2009 at 9:06 PM, Corey Ashford
> <cjash...@linux.vnet.ibm.com> wrote:
>>> The only reason you would want to expose that is for tools to either
>>> detect
>>> early on invalid event string or post-mortem print meaningful error
>>> messages.
>>> Other than that, what's the point of exposing that level of details?
>> Part of the reason would be transparency. Perhaps a tool would only display
>> the hard-wired options if verbose mode is turned on. Also, this flag could
>> be used within the library itself, and would provide a data-driven way to
>> set the attributes rather than hard-coding them ad hoc.
>>
> Fair enough.
>
>>> { .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 },
>>> }
>>> }
>>> The library would check that the event string contains at least one
>>> unit mask in each group. A simply mask would suffice. In this case,
>>> the bitmask would have to be equal to 0x3, otherwise there is an
>>> error (0x3 = (1 << event.ngrp) -1). Before making that final check, the
>>> library would look for a default in each group if one bit is missing from
>>> the mask.
>>>
>> Ah, interesting approach! Not only do you easily know there is one or more
>> missing (or two from a group are specified), but you know which ones are
>> missing and can fill them in if they have defaults.
>>
> Yes, exactly. Note that their can be more than one default per group, in which
> case they get concatenated.
Even better
...
> So I think in my example
> below, we need to provision for a .mods at the event level, not just the
> umask level.
>
>> This has always been unclear to me and I'm glad you brought up this up.
>>
>>
>>> We could easily define super-modifiers, internally the library would
>>> map that to each
>>> individual modifier + value.
>
> But with the .mods way of specifying hardwired modifiers, I wonder if there is
> still a new for super-modifiers. They are just aliases for a group of
> modifiers.
>
> I am not clear as to how you would include unit masks in this mechanism
> given the structure of the table. (event with optional umasks).
>
>> I think if we provide the exact translation, and a description, perhaps it
>> would be useful. I'm not 100% convinced this mechanism is needed, I just
>> thought it was fairly simple and expressive.
>>
>>>> In addition to this, perhaps I want the event to count level rather than
>>>> edges, but libpfm has determined edges to be the default. So another
>>>> group
>>>> would be for this choice:
>>>> "EDGES" -> "e=1"
>>>> "LEVEL" -> "e=0"
>>>>
>>> That seems less useful because the 'e' modifier is already published. So
>>> what's
>>> the value of adding yet another layer of indirection. Each modifier
>>> has a description
>>> that explain what it does.
>>>
>> The above example doesn't have more than one modifier, so it doesn't add
>> anything except a way of specifying the default value. However, if you have
>> a complex combination of modifiers that people would not want to have to
>> memorize, or copy/paste in from a document, perhaps its value would be more
>> evident.
>>
> I see.
>
>>> It seems to me that we are leaning towards some libpfm call that would
>>> describe what each event+attr actually define. You'd like for each event
>>> and for each unit mask to figure:
>>> - what is the unit mask code
>>> - what is the value of EACH modifier for it
>> Yes. Should I infer from this description, that we may not know what
>> modifiers apply to an event, nor perhaps their default values, unless we
>> know all of the umasks that have been added? I think I understand that, but
>> since I don't think I have a concrete example of that for Power, it's hard
>> for me to imagine.
>>
> Well, I think the modifiers operate at the event level not the unit mask
> level,
> even though I like you idea of masking the modifiers which are hardwired.
> Note that we could do that already at the event level. For instance the
> RS_UOPS_DISPATCHED_NONE example I gave above does the following:
> RS_UOPS_DISPATCHED:i=1:c=1. The modifiers are e,c,i,u,k. So here
> we could say, RS_UOPS_DISPATCHED_NONE only supports u,k because
> some are hardwired and 'e' would completely change the meaning of the event.
>
> So yes, I think you'd have to list the values of all modifiers ALSO at the
> event
> level.
>
>>> Let's take an example to illustrate what we would like. Let's assume
>>> we have the following event:
>>>
>>> attrs[]={
>>> 0 { .name = "e", .type = BOOL },
>>> 1 { .name = "i", type = BOOL },
>>> 2 { .name = "eth", .type = INTEGER},
>>> };
>>>
>>> { .name = "EVT1",
>>> .code = 0xa0,
>>> .ngrp = 1,
>>> .attrmsk = 0x7,
>>> .numasks = 2,
>>> .umasks = {
>>> { .name = "UM1",
>>> .code = 0x1
>>> .flags = IS_DEFAULT,
>>> .grp = 0,
>>> },
>>> { .name = "UM2",
>>> .mods = "e=1:eth=2",
>>> .code = 0x1
>>> .grp = 0,
>>> },
>>> }
>>> }
>>>
>>> The unit mask UM2 is a variation of UM1, except it has some modifiers
>>> hardcoded.
>>> Using a string may be a compact way of expressing hardcoded modifiers
>>> in the event
>>> table itself.
>> Ok, so you would combine the concept of umasks and macros into one thing
>> that can handle both?
>>
> 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.
> When queried for event info, the library would return foo. The
> description of foo would define
> it as equivalent to i=1:eth=2 and associate some meaning to the
> combination. Note that I have
> removed i, eth from the list of supported modifiers (attrmsk),
> therefore they are hardwired.
You also removed foo as specifiable, right?
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.
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.
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.
> If foo
> is just the default, then I could say attrmsk=0xf. Then it could be
> overriden by the user. We would
> have to sort out what to do with: EVT1:foo:i=0.
Yes, we'd get back to some of the issues we discussed earlier.
>> So, you're saying we could also provide another mechanism that would be
>> modifier macros without being coupled to a umask code?>> { .name = "EVT1",
>>> .code = 0xa0,
>>> .ngrp = 1,
>>> .attrmsk = 0x7,
>>> .numasks = 2,
> See above. Hopefully, I have described this clearly enough.
>
>> Assuming for now, the chip we're working on here doesn't need umasks, but
>> could use the macro capability, this would be our ticket, I think.
>>
> Note that what I describe is using the event table structure of X86. Of
> course,
> some of the logic could be duplicated for Power. But we need to figure out at
> which level all that string manipulation business is going to take place. In
> the
> current code base, the machine specific code does not see unit masks nor
> modifiers strings, it's been tokenized early on by the generic code. That
> means
> that we would have to add a bunch of need callbacks to retrieved the defaults
> and hardwired mods.
>
>> Using the structure you've provided, perhaps we'd just leave the .code field
>> to zero (or some other sentinel). Could that work?
>>
> We need to run through all you concrete cases and especially the difficult
> ones.
Agreed.
>
>> Any thoughts on the event-table-driven hard-wired modifiers would be
>> appreciated too. To be clear, this is not a need, but a want.
>>
> Did I not describe this?
You did in this post. There was some confusion earlier in the terminology
between hard-coded and hard-wired.
When I say hard-coded, I mean writing ad hoc logic, that could be based on a
event class (or even a particular event), which determines how to encode that
specific class of events, rather than driving it based on data in a table.
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.
--
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
------------------------------------------------------------------------------
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
