On Thu, Dec 4, 2008 at 1:37 AM, Corey J Ashford <[EMAIL PROTECTED]> wrote:
> Thanks for your reply.
>
> "stephane eranian" <[EMAIL PROTECTED]> wrote on 12/03/2008 04:05:01
> PM:
>
>>
>> One key principle of libpfm is that it tries to remain as
>> independent of perfmon
>> as possible. It does not use the same data structures nor flags. If
>> knowing whether
>> or not overflow is requested influences the choice of counters, then
>> libpfm must
>> definitively be informed. However, it would have to define its own
>> constant for
>> this.
>>
>> The next question is wether to use this constant in the generic flags
>> field or in
>> a Power specific structure, mod_in. With the former, it means we
>> need to change
>> all existing generic code to pass that constant with OVFL_NOTIFY is
> used.
>
> I'm not sure I understand why that would be necessary.  The other arches
> are currently ignoring that pfmlib_event_t.flags field, and they could
> continue to, since having OVFL_NOTIFY set or not does not affect their
> choice of register mapping.
>
But that flags is typically manipulated in generic code, not arch-specific.
So that means we would have to patch all programs to add that flag so
it would work when run on Power.

>> If
>> we store it in mod_in, then only Power code needs to be updated.
>>
>> I would go with the mod_in option and define a specific constant for it.
>>
>
> I'm ok with this, but it would mean that Power's mod_in would need an
> array that's parallel to the event array
> (pfmlib_input_param_t.pfp_events).  It's just a little ugly not to be able
> to associate this per-event data directly with the event, especially when
> it's a single bit that would fit nicely in the pfmlib_event_t.flags field.
>
We are already doing this for X86 both Intel and AMD to handle invert, edge
and counter mask filters. The distinction is generic vs. model specific. Your
need is machine specific. Looking at the code that handles this for some
X86 processors, I found a bug! So I am glad you brought this up.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to