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.
>>> Let me make one that's more complex than MESI and maybe more realistic.
>>> Let's say I have an event, call it EVT1, which normally I would want to
>>> specify that it's for my CPU thread, but in some cases I want to specify
>>> a
>>> mask which shows which CPU threads I want it to measure. So I set up a
>>> group containing three macros for EVT1:
>>> "THIS_CPU_THREAD" -> "ethm=0" // ethm is "enable thread mask"
>>> "ALL_CPU_THREADS" -> "ethm=1:thm=0xff" // thm is the thread mask,
>>> assuming
>>> 8 threads
>>> "SOME_CPU_THREADS" -> "ethm=1" // user must specify thm value now (this
>>> macro is really not that useful)
>>>
>> Ok, so here you are talking about a macro to represent a group of
>> preset modifiers.
>
> Yes, but could also include umasks.
>
> I must be missing something important about unit masks, then. Why would
> modifiers need to be coupled with unit masks? Can't I have an event with
> just a set of modifiers? I was thinking that umasks are sort of an "enum"
> type to modify an event.
>
Yes, you can. I missed that point. It's just that on X86 it's not that common.
There is one case on Core 2 with one event, no unit mask, yet hardwired
modifiers (RS_UOPS_DISPATCHED_NONE). 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.
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. 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.
>
> 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.
> 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?
------------------------------------------------------------------------------
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
