Hi Stephane And Richard, > Richard, > > On Thu, Mar 22, 2007 at 12:10:46PM -0400, Richard C Bilson wrote: >> Hello Stephane and others, >> >> As part of our work on uProfiler we are using perfmon to self-sample >> multithreaded programs. Specifically, we have programs with multiple >> kernel threads, each with their own perfmon context, each requesting >> overflow interrupts through SIGIO. >> >> The behavior that's troubling me right now is that there appears to be >> no guarantee that the SIGIO is delivered to the same kernel thread that >> caused the corresponding counter overflow. Specifically, I find our >> SIGIO handler being activated on a particular kernel thread with >> siginfo's si_fd member referring to the context of a different kernel >> thread. >> > You are perfectly right, POSIX does not stipulate that SIGIO goes to the > thread that generated the event. In general asynchronous signals cannot > be targeted to a particular thread. I ran into this myself with earlier > version of pfmon. There is nothing I can do about it in perfmon. You'd > have > to structure your code differently or use the trick you are using, i.e., > based on the fd forward to the right thread. One thing is sure, is that > the signal is not delivered to a thread that blocks the signal. So you > could have all but one thread block the signal and then dispatch from > there.
I also ran out of it and there seems to be a way out (atleast according to the man pages on some latest kernel versions). I am quoting the following from manpage of fcntl: "If a non-zero value is given to F_SETSIG in a multi-threaded process running with a threading library that supports thread groups (e.g., NPTL), then a positive value given to F_SETOWN has a different meaning: instead of being a process ID identifying a whole process, it is a thread ID identifying a specific thread within a process. Consequently, it may be necessary to pass F_SETOWN the result of gettid() instead of getpid() to get sensible results when F_SETSIG is used. (In current Linux threading implementations, a main threads thread ID is the same as its process ID. This means that a single-threaded program can equally use gettid() or getpid() in this scenario.)" Infact, I was also facing the same issues and I have implemented the above methods. I have yet to analyse my results closely but my initial impressions are that I see some loss of samples and the signals going to the unintended threads. If anyone of you gets any insight on this, kindly let me know. >> I can understand why this behavior might suit some applications, but it >> poses real problems for us: we use overflow notifications as a cue to >> sample a variety of bits of application state on that kernel thread, so >> getting the notification on a different thread doesn't help us. >> >> As of now, I haven't been able even to craft an effective work-around. >> The best I can come up with is to detect a signal on the "wrong" thread >> and respond with a pthread_kill to the right thread. But that seems >> like it would significantly increase not only our probe effect but, >> more importantly, the time between overflow and sample. >> >> I hope someone can tell me that there's an obvious switch that I've >> overlooked, but I appreciate any comments or ideas. >> >> Thanks. >> -- >> Richard C. Bilson, Research Assistant [EMAIL PROTECTED] >> http://plg.uwaterloo.ca/~rcbilson >> D. R. Cheriton School of Computer Science, University of Waterloo >> 200 University Avenue West, Waterloo, Ontario, CANADA N2L 3G1 >> _______________________________________________ >> perfmon mailing list >> [email protected] >> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ > > -- > > -Stephane > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ > Regards, Vivek --------------------- MS, CSC Department NC State University 2834 Avent Ferry Road, Apt. 202 Raleigh, NC, 27606 _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
