From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29148 invoked by alias); 25 Nov 2009 17:46:24 -0000 Received: (qmail 29137 invoked by uid 22791); 25 Nov 2009 17:46:22 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Nov 2009 17:46:17 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAPHkGw8020015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Nov 2009 12:46:16 -0500 Received: from tranklukator.englab.brq.redhat.com (tranklukator.englab.brq.redhat.com [10.34.32.241]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id nAPHkE1N014945; Wed, 25 Nov 2009 12:46:14 -0500 Received: by tranklukator.englab.brq.redhat.com (nbSMTP-1.00) for uid 500 onestero@redhat.com; Wed, 25 Nov 2009 18:41:03 +0100 (CET) Date: Wed, 25 Nov 2009 17:46:00 -0000 From: Oleg Nesterov To: Ingo Molnar Cc: Masami Hiramatsu , lkml , Roland McGrath , Jason Baron , systemtap , DLE Subject: Re: [PATCH -tip v3 0/3] tracepoint: Add signal events Message-ID: <20091125174101.GA18349@redhat.com> References: <20091120213108.14708.97871.stgit@dhcp-100-2-132.bos.redhat.com> <20091123175740.GA15594@elte.hu> <20091124212247.GA11773@redhat.com> <20091124213727.GA11347@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091124213727.GA11347@elte.hu> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00708.txt.bz2 On 11/24, Ingo Molnar wrote: > > * Oleg Nesterov wrote: > > > 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? Yes, right. My point was, we do not know if people want to know about "lost" signal in this case. Perhaps some application forgot to unblock the signal, or the sender shouldn't send it, or the reciever didn't react to the previous one. But once again, I do not argue. I think the patches are nice and useful. All I wanted to say is: I trust Masami and I have no idea whether we need more or less info, and which events are more "interesting". > > [...] We do not report who sends the signal, [...] > > The PID of any task generating an event can be sampled, so that's > implicit. Yes, I missed this. If current != sender (timers, SIGIO) one can look at entry->code = si_code. > 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) Fortunately, Roland has already replied: > If we > need to change them, that will become clear from the experiences of people > actually using these. In fact, the above is very close to what I meant but failed to explain ;) Oleg.