Exactly! If the driver is doing it's job, then the problem's likely in the handler. It's that loop over all the fd's that's needed.
stephane eranian wrote: > Rob, > > On Fri, Apr 18, 2008 at 5:09 PM, Rob Fowler <[EMAIL PROTECTED]> wrote: >> I've been spending way too much time being a manager lately >> to actually dig around in the Perfmon code, >> but my gut feeling on this issue continues to be that the >> problem is one of two things: >> >> Second, the PAPI workaround of using SIGRTMIN rather than SIGIO leads me >> to suspect that a second or third trap occurs while the first is being >> handled and that going to queued signals ensures that multiple events are >> delivered in separate signals. This is a consequence of usgin a >> "1-signal = 1-event" assumption. >> > This interpretation is not imposed by the interface. This is an > assumption made by > the signal handler. > > Perfmon does send one signal per 64bit overflow but it also enqueues > one message per > context. If signal get aggregated, then sure you will "miss" some > overflows. However > the information is not completely lost as the messages are still > enqueue. In the handler > you could simply poll all perfmon file descriptors using a > non-blocking read on each fd. > That way you would be sure you've swept all possible source of overflows. -- Robert J. Fowler Chief Domain Scientist, HPC Renaissance Computing Institute The University of North Carolina at Chapel Hill 100 Europa Dr, Suite 540 Chapel Hill, NC 27517 V: 919.445.9670 F: 919 445.9669 [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ perfmon2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
