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.
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/
