HI folks,
We're seeing similiar issues on the MIPS port of Perfmon2 with
HPCtoolkit and PAPI. However, I'm dead certain I have put F_SETSIG
and gettid stuff in the code, but yet we're still seeing samples in
the wrong thread. I'll get back to you and confirm.
Phil
On Mar 22, 2007, at 9:39 PM, Vivek Thakkar wrote:
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 threadÂ’s 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/
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
