From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751306AbdBWIN6 (ORCPT ); Thu, 23 Feb 2017 03:13:58 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56007 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751033AbdBWINz (ORCPT ); Thu, 23 Feb 2017 03:13:55 -0500 Subject: Re: [RFC] perf/sdt: Directly record SDT event with 'perf record' To: Arnaldo Carvalho de Melo References: <20170203151826.GA2712@redhat.com> <20170216101617.4791-1-ravi.bangoria@linux.vnet.ibm.com> <20170220070851.GA8974@gmail.com> <58AAA712.5040408@linux.vnet.ibm.com> <20170220084224.GA24404@gmail.com> <58AACC9E.8070009@linux.vnet.ibm.com> <20170220141117.GJ4109@kernel.org> Cc: Ingo Molnar , masami.hiramatsu.pt@hitachi.com, mingo@redhat.com, brendan.d.gregg@gmail.com, peterz@infradead.org, alexander.shishkin@linux.intel.com, wangnan0@huawei.com, jolsa@kernel.org, ak@linux.intel.com, treeze.taeung@gmail.com, mathieu.poirier@linaro.org, hekuang@huawei.com, sukadev@linux.vnet.ibm.com, ananth@in.ibm.com, naveen.n.rao@linux.vnet.ibm.com, colin.ing@canonical.com, adrian.hunter@intel.com, linux-kernel@vger.kernel.org, hemant@linux.vnet.ibm.com, Ravi Bangoria From: Ravi Bangoria Date: Thu, 23 Feb 2017 13:43:38 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170220141117.GJ4109@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022308-0004-0000-0000-000011AAD39D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006667; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000204; SDB=6.00825878; UDB=6.00404428; IPR=6.00603328; BA=6.00005166; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014404; XFM=3.00000011; UTC=2017-02-23 08:13:52 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022308-0005-0000-0000-00007D4F04B0 Message-Id: <58AE99B2.7090202@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702230080 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks Arnaldo, I'm working on this but it's taking bit longer time. Will post out a patch within few days. Ravi On Monday 20 February 2017 07:41 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, Feb 20, 2017 at 04:31:50PM +0530, Ravi Bangoria escreveu: >> Thanks Ingo, >> >> On Monday 20 February 2017 02:12 PM, Ingo Molnar wrote: >>> * Ravi Bangoria wrote: >>> >>>> What should be the behavior of the tool? Should it record only one >>>> 'sdt_libpthread:mutex_entry' which exists in uprobe_events? Or it >>>> should record all the SDT events from libpthread? We can choose either >>>> of two but both the cases are ambiguous. >>> They are not ambiguous really if coded right: just pick one of the outcomes and >>> maybe print a warning to inform the user that something weird is going on because >>> not all markers are enabled? >>> >>> As a user I'd expect 'perf record' to enable all markers and print a warning that >>> the markers were in a partial state. This would result in consistent behaviour. >> Yes, makes sense. >> >>> Does it make sense to only enable some of the markers that alias on the same name? >>> If not then maybe disallow that in perf probe - or change perf probe to do the >>> same thing as perf record. >> 'perf probe' is doing that correctly. It fetches all events with given name from >> probe-cache and creates entries for them in uprobe_events. >> >> The problem is the 2-step process of adding probes and then recording, >> allowing users to select individual markers to record on. > So, the more streamlined one works for most people, i.e. just use perf > record, no need to perf probe anything. But, for people who "know what > they are doing", perf probe can be used first to control exactly which > SDT probes one wants in place, and then those will be used. > > We need to make sure that when processing the file there is information > that says which probes were in place and enabled in the record session, > tho. Is that possible? > >>> I.e. this is IMHO an artificial problem that users should not be exposed to and >>> which can be solved by tooling. >>> >>> In particular if it's possible to enable only a part of the markers then perf >>> record not continuing would be a failure mode: if for example a previous perf >>> record session segfaulted (or ran out of RAM or was killed in the wrong moment or >>> whatever) then it would not be possible to (easily) clean up the mess. >> Agreed. We need to make this more robust. > Right, disambiguating a 'probes left by a session that did auto-probing' > from a 'hey, those probes are there intentionally, just use those' is > important. > >>>> Not allowing 'perf probe' for SDT event will solve all such issues. >>>> Also it will make user interface simple and consistent. Other current >>>> tooling (systemtap, for instance) also do not allow probing individual >>>> markers when there are multiple markers with the same name. >>> In any case if others agree with your change in UI flow too then it's fine by me, >>> but please make it robust, i.e. if perf record sees partially enabled probes it >>> should still continue. >> @Masami, can you please provide your thoughts as well. > Yeah, if technically possible to allow both variants, we should leave > it up to users to decide what is best? > > I.e. most people will do auto-probing, not using 'perf probe' at all, > documentation should state the pitfalls in doing so. > > So, after writing the above, perhaps we should warn the user that > pre-existing probes are being used, as this will be the odd case? > > The normal flow will be just using perf record with SDT probes, that > will auto-probe them and remove on exit, or better drop a reference to > them, as simultaneous use also needs to be covered? > > - Arnaldo >