stephane eranian wrote:
> Corey,
>
> On Tue, Dec 8, 2009 at 11:49 PM, Corey Ashford
> <cjash...@linux.vnet.ibm.com> wrote:
>> To give a more concrete example, in the processor I'm working on, there is a
>> class of events for which you can set the mode to level or edge counting,
>> depending on what information you want out of it. However, we generally
>> know that most users are going to want, for example, edge counting for these
>> events, so we provide that as a default, but will allow that default to be
>> overridden, or explicitly specified to be the same as the default value, so
>> that, for example:
>>
>> EVENT
>> is equivalent to
>> EVENT:e=1
>> but can be overridden as
>> EVENT:e=0
>>
> Yes, that's what I would expect for a default. It's there is the modifier is
> not specified, but it is skipped if the modifier is specified by the user.
>
>> Of course the other way to approach this is that if there's any choice,
>> force the user to make a choice rather than assume anything about what he
>> wants.
>>
> That's what happens today with unit masks, but not with modifiers.
>
>> Perhaps another way, would be to have an additional flag called
>> is_hard_wired which is mutually exclusive with is_dfl. This way you could
>> display the hard-wired umasks and modifier values to the user, but let them
>> know they can't change them.
>>
> 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.
>
>>> need to extend this notion. For instance,
>>>
>>> EVENTA:
>>> grp1: A, B, C
>>> grp2: D, E, F, G
>>>
>>> That means that you need to set at least one mask in grp1 and one in grp2:
>>> EVENTA:A:D is okay
>>> EVENTA:A:B:F is okay
>>> EVENTA:C is bad
>>> EVENTA:FG is bad
>>>
> I have been thinking about the grouping issue some more. I think I
> have a solution
> to ensure that at least one elment of each group is selected either
> explicitly or
> because it has a default. This is similar to coloring. In the table you tag
> each
> unit mask, with a group id. In each group at least one unit mask must be set.
> If it is not and there is no default, then there is an error. At the
> event level,
> the table would contain the number of groups. to get back to me example
> above:
>
> { .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.
>>>> A more complex case might be:
>>>>
>>>> "SOME_GROUP" -> "E:x=0x100:tm=4:k=1:h=1"
>>>>
>>> See my answer above about how to hardcode this.
>> If the hard-coding allows encoding the setting of multiple modifiers/umasks,
>> I think this should be fine. I just don't see how to mix different
>> attributes into a single member of a group, given the structure you provided
>> in the previous post.
>>
> Yes, I think there is an issue if you want to report that an
> attribute, e.g., a unit
> masks hardcodes a unit mask code + a bunch of modifiers.
>
>> 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.
> And then, I am assuming you use that in the list of unit masks for an
> event or as
> a attribute of a unit mask.
>
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.
This has always been unclear to me and I'm glad you brought up this up.
> It's as if you were defining super-modifiers which gather a set of
> modifiers + values.
Exactly.
> We could easily define super-modifiers, internally the library would
> map that to each
> individual modifier + value.
>
> I think what is more difficult in all of this is how to report this to
> the user (assuming
> it could be useful).
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.
>> The default for a particular group is the first one in the group. With
>> these two groups, if I specify just "EVT1", I will effectively get
>> "EVT1:ethm=0:e=1". Since I want level counting, I should specify
>> "EVT1:LEVEL" or equivalently "EVT1:e=0".
>>
> 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.
>
> That is different from what i was proposing which was simply iterating
> over each attribute individually reporting its code and whether or not
> it was the default.
>
> I believe the former proposal is probably more useful to applications.
> Yet it is more difficult to create data structures to represent the
> information
> because the number of modifiers is highly variable.
>
> 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?
>
> The next challenge is how to expose this to the user: maybe as a
> string.
> It may be easier
> for a tool to use strstr() to detect whether or not certain modifiers
> were specified wrongly.
> That is also very flexible and extensible.
I don't follow how you'd use strstr to detect wrongly specified modifiers.
>
> The get_event_attr_info() would return the mods string for each unit
> mask along with
> whether or not it is default or not. Calling this function with an
> index of a attribute
> that corresponds to a modifier could be useful for some modifiers such
> as priv level.
Sounds good.
>
> Note that this scheme would not prevent what you proposed with super-modifiers
> representing groups of modifiers.
>
> Does it cover all the needs you've expressed?
>
So, you're saying we could also provide another mechanism that would be
modifier
macros without being coupled to a umask code?
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.
Using the structure you've provided, perhaps we'd just leave the .code field to
zero (or some other sentinel). Could that work?
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.
Thanks,
- 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
