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
and would that differ from
FOO_EVENT:x=8:DFL_GROUP
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?
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"
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.
>
>> I would assume it would be, and we'd have to come up with some way of
>> detecting these sorts of errors. If it would be legal to specify one group
>> and then alter it with an individual attribute, would the semantics differ
>> from specifying them in the opposite order?
>>
>> L2_LD:M=0:MESI
>>
> Same explanation as above.
>
>
>> In this case I'm saying, I want M=0 but MESI otherwise...
>>
>> Assuming this mixing groups and individual attributes is just not allowed,
>> would the following be an error?
>> L2_LD:M=0
>>
>> ... where you only specify one of the individual attributes and not the
>> others... do the others default to something? They have is_dfl set to zero,
>> but can they still have default values? Or do you start with the default
>> group, and then allow modification of individual attributes (i.e. L2_LD:M=0
>> would be sort of an implicit L2_LD:MESI:M=0)
>>
>> Also, there definitely needs to be error checking against specifying two
>> groups:
>>
>> L2_LD:ANY:CORE_BOTH:CORE_SELF
>>
> Yes, in this unit mask group at most of mask can be set.
>
> This gets me to the next challenge: how to expressed these constraints
> on the unit masks in the table?
> Today, on X86, the only constraint we know about is NCOMBO which
> means you can have at most of unit mask at a time. But here we are
> looking at something far more complicated with unit mask groups.
> Maybe we could get by by simply implementing this in the actual
> code and not in the table. This is how it's done today for MESI
> and CORE_SELF/CORE_BOTH. The number of events where you
> have to deal with this is fairly minimal on X86.
Well, if the groups were in a string list, you could limit the event specifier
to having a single macro usage per list. Maybe there could be multiple lists
per event, though. For example, you might have a default macro for u,k,h and
another default macro for MESI.
Initially, though, I think we could just leave the constraint checking out and
just let later macros, umasks, and modifiers override earlier ones in the
string.
--
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
