Hi Stephane, stephane eranian wrote: > Hello John, > > > On Fri, May 1, 2009 at 12:51 AM, john <sy...@viscous.org> wrote: > >> Hello Stephane et al., >> >> My goal is to have an arbitrary number of threads monitor themselves, >> each being interrupted after approximately 1ms worth of clock cycles >> have gone by. Libpfm's example program self_smpl_multi seemed to do >> something similar, so I rewrote it to take an arbitrary number of >> threads and an arbitrary number of desired interrupts per second. >> >> I followed self_smpl_multi's technique of arranging to receive a SIGIO >> in the thread associated with the Perfmon context, landing in the >> registered signal handler. The threads continue running until they've >> reached the targeted number of interrupts. For example, 10 >> interrupts/second times five seconds of runtime would be 50 total >> interrupts. >> >> This approach works fine up to about 25 interrupts/thread/second on my >> Intel Core2 Quad (4 core) system. After that, some of the threads never >> stop. Peering at the program in GDB leads me to believe that one or more >> threads doesn't get SIGIO anymore. My current guess is that if any one >> thread is handling SIGIO, any new notifications on other threads just >> get dropped on the floor; the descriptor doesn't get read, so the signal >> handler doesn't get invoked anymore. >> >> > Yes, you are running into the issue with the pthread signal model. There is > no guarantee asynchronous signals such as SIGIO get delivered to the right > thread. Last time I looked a the kernel code, it works as a job queue for the > process, which ever thread is exiting the kernel may pickup the next signal > job on the queue. Therefore it is not possible to guarantee which thread is > going to get called. But this is also why, the handler you be > prepared to handle > notifications from another thread. The file descriptor should be sufficient to > identify which thread the overflow originated with. > > > I do wish for the target threads themselves to be interrupted; this is so I can do things like periodic stack traces. Therefore, handling SIGIO in a different thread won't be sufficient. Is there any interest by others in a mechanism like this? Since Perfmon makes the kernel information available via a file descriptor, there aren't any reliable ways to interrupt the target thread when the PMU overflows. In theory, Perfmon could, for example, run a user-specified callback when the counter overflows. Since the thread is interrupted anyway, it could do this by simply delivering a signal directly to the target thread, and let the signal handling system do the rest. I don't really know Linux kernel internals, but it looks like send_sig() might do this.
> > >> Would real time signals help me here (to queue up the signals), or is >> there some other approach to thread interruption I should explore? >> >> > It seems that using realtime signals does help, use a signal >33 and > you should get a better behavior. > I've tried this, and while signals do seem to get reliably delivered, they sometimes end up getting delivered to the wrong thread. Thanks again, john ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
