"stephane eranian" <[EMAIL PROTECTED]> wrote on 12/03/2008 05:02:03 PM:
> 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. Sorry, I'm not following still. The need I have is model specific, if I understand the meaning of "model" correctly. This flag would matter only for Power6 (PPC970, Power4,5 would be coded to ignore the flag). It seems that this use would be similar to Atom's need for invert, edge, etc. Are you arguing for purposes of backward-compatibility? That if mod_in is set to null, we do what we used to do? I don't think we have a large user base for perfmon2 on Power yet, so this is probably not a big issue. I can create an appropriate fix for PAPI/perfmon2 at the same time. Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
