Corey, On Wed, Dec 3, 2008 at 9:45 PM, Corey Ashford <[EMAIL PROTECTED]> wrote: > Hi Stephane, > > One of the issues I ran into with the Power6 port of perfmon2, which > hasn't been resolved (I forgot about it :( ), is that > pfm_dispatch_events doesn't give the function enough information to > choose the correct group in some cases. What's missing is whether or > not the caller is going to want to set PFM_REGFL_OVFL_NOTIFY on a > particular event. In the case of Power6, this is a problem because > pfm_dispatch_events may choose a group in which one or two of the events > are mapped to counters which do not interrupt on overflow - counters 5 & 6. >
> There's an error in the current implementation that we ignore the > PFM_REGFL_OVFL_NOTIFY flag for counters 5 & 6 when it comes to the > pfm_write_pmds call. If the implementation were [more] correct, we > would reject a call to write counters 5 or 6 with that flag set. The > code that implements PFM_REGFL_OVFL_NOTIFY is in perfmon_rw.c and is not > accessible to arch-specific code (from what I can tell). To fix this, > we'd have to insert some new arch-independent code. > > However, even this would not be a good solution, because the caller, > ideally, should be informed at the time of the pfm_dispatch_events call > that perfmon would be unable to support their overflow notify request. > And, actually, in some cases, if pfm_dispatch_events knew that overflow > was going to be needed on these two events, it might be able to find > another group with these same events, but counted on counters that > support interrupt on overflow. > > In the structure, pfmlib_event_t, there is a "flags" field provided. It > isn't described in the man page for pfm_dispatch_events. Would it make > sense for this flags field to take PFM_REGFL_OVFL_NOTIFY as one of its > flag values? Or would a better place be to add a Power-specific mod_in > structure? 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. If we store in 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. If we do it in flags, then it means we need to modify all ------------------------------------------------------------------------- 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
