lkml.org 
[lkml]   [2009]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: perf_counters issue with self-sampling threads
From
[Reposting the message because of stupid MIME-encoding error on my part]
Andi,

Looks like SIGPROF is calling _group_send_sig_info(), so I
think it is subject to the same problem.

I have built a perfmon example to test the problem, it is
relatively easy to trigger by simply self-monitoring a thread
which is using setitimer() and thus SIGALRM. You just have
to increase the timer frequency. At some point, the SIGPROF
signal will be delivered to the wrong thread.

One thing I did not mention in my message is that one would think
that forcing a specific signal via F_SETSIG could be a workaround
if that signal is synchronous, e.g., SIGFPE. F_SETSIG looks like a
Linux extension but it does not solve the problem. Linux determines
the mode of delivery not on the signal number but on the code path,
it seems. If you use F_ASYNC+F_SETOWN, then this is systematically
considered asynchronous regardless of the signal used.If you come from
traps.c, then the signal is delivered to the correct thread. All of this does
not look unreasonable to me.

I believe sampling, be it timer or PMU-based, may be
a special case here. We want asynchronous + specific
thread (only) when self- sampling.

An alternative may be to choose the pending queue based on the signal type
(synchronous, asynchronous). Then, we could use F_SETSIG to override
SIGIO with a synchronous signal instead. But I am not a POSIX signal expert.


On Jul 27, 2009 11:25 PM, "Andi Kleen" <andi@firstfloor.org> wrote:


I wonder how SIGPROF gets around the same problem, or is it
buggy too?

-Andi

--
ak@linux.intel.com -- Speaking for myself only.


\
 
 \ /
  Last update: 2009-07-28 10:53    [W:0.110 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site