Vivek, On Thu, Sep 06, 2007 at 08:04:57PM -0400, [EMAIL PROTECTED] wrote: > Stephane, > > > I think there maybe a problem with this approach because it seems hard > > to guarantee which thread is going to receive the signal. Note that in > > system-wide your monitoring program is probably doing nothing more than to > > wait for the signal, in which case, it might as well, block on > > read(fd,&msg). The workload you are running could as well run in a separate > > program pinned to the core. > > > > As suggested by you, I want to try out monitoring(of all the threads' events > ) > by a single thread . Do you have any example of the same ? I grepped for > PFM_FL_NOTIFY_BLOCK (which I guess I would need to stop the thread which got > overflow signal) and found that multiplex.c does trace some other process. > Can you give me some example of how to do this with threads ? >
In system-wide or per-thread, you can figure out which context the SIGIO is for by look at the file descriptor reported in the siginfo (si_fd) structure. If I recall this one is correct. Alternatively, you can create a multi-processor tool, instead of multi-threaded tool. > Specifically, how would an overflow signal (SIGIO which will be handled by > master thread only) identify the thread for which it has come ? > Look at the siginfo->si_fd field. It should give you the perfmon context from which the signal is coming from. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
