On Mon, Dec 7, 2009 at 10:46 PM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
> Hi Stephane,
>
> stephane eranian wrote:
>>
>> On Fri, Dec 4, 2009 at 11:16 PM, Corey Ashford
>> <cjash...@linux.vnet.ibm.com> wrote:
>>
>>> I assume this is supposed to be
>>> .uname = "CORE_SELF",\
>>>
>>>> .udesc = "This core",\
>>>> .ucode = 0x40\
>>>> },\
>>>> { .uname = "BOTH_CORES",\
>>>
>>> and
>>> .uname = "CORE_BOTH",\
>>>
>>>> .udesc = "Both cores",\
>>>> .ucode = 0xc0\
>>>> }
>>>>
>> Yes.
>>
>>
>>>> In this particular case, a reasonable default would be
>>>>
>>>> L2_LD:ANY:MESI:CORE_SELF:u=1:k=0:i=0:e=0:c=0
>>>>
>>>> I think the only reasonable approach would be for the
>>>> tool to iterate over all the attributes and query 'default'
>>>> information. So here, it would return:
>>>>
>>>> M: is_dfl=0
>>>> E: is_dfl=0
>>>> S: is_dfl=0
>>>> I: is_dfl=0
>>>> MESI: is_dfl=1 value=0xf (unit mask value)
>>>> CORE_BOTH: is_dfl=0
>>>> CORE_SELF: is_dfl=1
>>>> u: is_dfl=1 value=1
>>>> k: is_dfl=0
>>>> i: is_dfl=0
>>>> e: is_dfl=0
>>>> c: is_dfl=0
>>>
>>> Just so I'm certain I understand what you are saying, if I specify
>>>
>>> L2_LD:MESI:M=0
>>>
>>> would that be an error (because M=0 conflicts with MESI) ?
>>>
>> I assume you mean M as in Modified, i.e,, from MESI. In this
>> case, you would get an error because MESI are managed as
>> unit masks, not modifiers. You'd get an error because there is
>> no modifier called M.
>>
>> But going back to your example:
>> L2_LD:MESI:M
>>
>> This would be legal because MESI bits can be combined. That would
>> be a stupid combination because you would end up measuring MESI.
>> The library would have to ensure that there is either at least one
>> unit mask set per group (here the group is M, E, S, I) or it would pick
>> the default (here MESI).
>
> I think I was a bit confused because there was no group description for
> INTEL_CORE_MESI_UMASKS.
>
> I see how it works for unit masks, but what about modifiers with values?
>
> Let's say I have a group called DFL_GROUP which, as one of the things it
> does
> sets an integer modifier x to 0. Could I do this:
>
> FOO_EVENT:DFL_GROUP:x=8
>
I think we need to distinguish between default and hardcoded as part of a
unit mask. In your case I suspect x=0 is part of DFL_GROUP, i.e., it is
necessary for DFL_GROUP to measure what its definition says it measures.
In that case, x=8, would be illegal. That's different from a default which
is not part of any specific unit mask definition but it will be used if the
user omits the modifiers (or unit mask).
Another way of looking at it would be to let the user make mistakes.
Let the user override x with 8.
The existing X86 libpfm4 codebase, refuse to set the value of a modifier
if it is already not zero. But that's specific to X86. It may be that on
Power, a value of 0 may be required for certain unit masks. 0 is just
the neutral value on X86, it could be something else on Power. This is
all in PMU specific code for this reason.
> and would that differ from
>
> FOO_EVENT:x=8:DFL_GROUP
>
With the first approach, you would fail DFL_GROUP because it sets a modifier
already set by the user. With the second approach, DFL_GROUP would override
x=8.
> Or perhaps I am misunderstanding how groups work? Re-reading your proposal,
> it seems that what a group actually does is not encoded into the data
> structure, but rather into the libpfm code. Is that correct?
>
I was thinking of groups more in terms of unit masks. A group
represents a choice of
unit masks to choose from, where at least one must be set. An event may have
more than one group, i.e., at least of mask in each group must be set.
The current
implementation has one group per event (when they have unit masks). I think we
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 think your example adds to this by saying mask A comes from x=0.
I think this info can be hardcoded as part of the unit mask code. This is how
it's done on X86. Of course, you need a way to identify the value that means
'not set'. If that's not possible, then you need to augment the event structure
with a field that encodes this.
> Maybe another way to handle groups is to use "macros" which translate the
> group name string into lower-level umask and modifier strings processed in
> the normal way. As a very simple example:
>
> "MESI" -> "M:E:S:I"
>
> 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.
> All defaults could be done via macros. If no macro string within list for a
> specific event is specified, the first one in the list is the default.
> Something like that. Doing this would keep you from having to handle all of
> this in code; the data would drive the translation. These translations
> would have to be event-specific, at worst.
Please show me a concrete example of the macros.
------------------------------------------------------------------------------
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
