From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18246 invoked by alias); 24 Nov 2009 21:56:45 -0000 Received: (qmail 18231 invoked by uid 22791); 24 Nov 2009 21:56:44 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fallback.mail.elte.hu (HELO fallback.mail.elte.hu) (157.181.151.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 21:56:38 +0000 Received: from mx3.mail.elte.hu ([157.181.1.138]) by fallback.mail.elte.hu with esmtp (Exim) id 1ND3NB-000424-P1 from ; Tue, 24 Nov 2009 22:56:33 +0100 Received: from elvis.elte.hu ([157.181.1.14]) by mx3.mail.elte.hu with esmtp (Exim) id 1ND34s-0002dF-PR from ; Tue, 24 Nov 2009 22:37:39 +0100 Received: by elvis.elte.hu (Postfix, from userid 1004) id 064113E22E5; Tue, 24 Nov 2009 22:37:28 +0100 (CET) Date: Tue, 24 Nov 2009 21:56:00 -0000 From: Ingo Molnar To: Oleg Nesterov Cc: Masami Hiramatsu , lkml , Roland McGrath , Jason Baron , systemtap , DLE Subject: Re: [PATCH -tip v3 0/3] tracepoint: Add signal events Message-ID: <20091124213727.GA11347@elte.hu> References: <20091120213108.14708.97871.stgit@dhcp-100-2-132.bos.redhat.com> <20091123175740.GA15594@elte.hu> <20091124212247.GA11773@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091124212247.GA11773@redhat.com> User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00692.txt.bz2 * Oleg Nesterov wrote: > On 11/23, Ingo Molnar wrote: > > > > * Masami Hiramatsu wrote: > > > > > Hi, > > > > > > These patches add signal related tracepoints including > > > signal generation, delivery, and loss. First patch also > > > moves signal-sending tracepoint from events/sched.h to > > > events/signal.h. > > > > > > Changes in v3 > > > - Add Docbook style comments > > > > > > Changes in v2 > > > - Add siginfo arguments > > > > > > Thank you, > > > > > > --- > > > > > > Masami Hiramatsu (3): > > > tracepoint: Add signal loss events > > > tracepoint: Add signal deliver event > > > tracepoint: Move signal sending tracepoint to events/signal.h > > > > > > > > > Documentation/DocBook/tracepoint.tmpl | 5 + > > > include/trace/events/sched.h | 25 ----- > > > include/trace/events/signal.h | 173 +++++++++++++++++++++++++++++++++ > > > kernel/signal.c | 27 ++++- > > > 4 files changed, 198 insertions(+), 32 deletions(-) > > > create mode 100644 include/trace/events/signal.h > > > > Would be nice to have Roland's and Oleg's Acked-by tags in the patches - > > to show that this is a representative and useful looking set of signal > > events. > > Sorry, I can't really comment these patches. > > I mean, I do not know which info is useful and which is not. For > example, I am a bit surprized we report trace_signal_lose_info() but > please do not consider this as if I think we shouldn't. Just I do not > know. well, there we lose information, so it's basically an exception/anomaly that a person doing analysis might be interested in. > OTOH, we do not report if __send_signal() fails just because the > legacy signal is already queued. [...] We could do that (beyond the queued signals full event), but i think it's rather common to see signal overlap in the legacy case, right? > [...] We do not report who sends the signal, [...] The PID of any task generating an event can be sampled, so that's implicit. > [...] we do not report if it was private or shared. zap_process, > complete_signal can "send" SIGKILL via sigaddset, this won't be > noticed. But again, it is not that I think this should be reported. > > In short: I think any info may be useful, and these patches can help. > But I do not understand what exactly should be reported to userspace. The principe is this: there's two extremes: A- report no event B- report every event precisely, that allows all signal state and actions to be reconstructed in hindsight. And there's a continuum between the two extremes. Just a random state between A) and B) makes little sense - but certain subsets (say an 'overview' of major signal events) might make sense from an analysis POV. But the thing is, by my reading of these patches we are pretty close to B) right now and the tracepoints still look sane - so we might as well implement your suggestions and achieve B)? That's a well-defined target to achieve. It would mean we need events of sigmask manipulations as well, and handler setting events. Plus the missing events you pointed out. (plus other stuff i might have forgotten about) Ingo