From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751634AbdBTIV4 (ORCPT ); Mon, 20 Feb 2017 03:21:56 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53490 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbdBTIVy (ORCPT ); Mon, 20 Feb 2017 03:21:54 -0500 Subject: Re: [RFC] perf/sdt: Directly record SDT event with 'perf record' To: Ingo Molnar References: <20170203151826.GA2712@redhat.com> <20170216101617.4791-1-ravi.bangoria@linux.vnet.ibm.com> <20170220070851.GA8974@gmail.com> Cc: mingo@redhat.com, acme@kernel.org, masami.hiramatsu.pt@hitachi.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: Mon, 20 Feb 2017 13:51: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: <20170220070851.GA8974@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022008-8235-0000-0000-00000B01B932 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006649; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000203; SDB=6.00824442; UDB=6.00403575; IPR=6.00601899; BA=6.00005155; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014354; XFM=3.00000011; UTC=2017-02-20 08:21:51 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022008-8236-0000-0000-000039BE8327 Message-Id: <58AAA712.5040408@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-20_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-1702200084 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 20 February 2017 12:38 PM, Ingo Molnar wrote: > * Ravi Bangoria wrote: > >> All events from 'perf list', except SDT events, can be directly recorded >> with 'perf record'. But, the flow is little different for SDT events. >> Probe point for SDT event needs to be created using 'perf probe' before >> recording it using 'perf record'. >> >> As suggested by Ingo[1], it's better to make this process simple by >> creating probe points automatically with 'perf record' for SDT events. >> >> This patch disables 'perf probe' on SDT events to simplify usage. It >> enables recording SDT event only with 'perf record'. >> >> This removes all those 'multiple events with same name' issues by not >> allowing manual probe creation to user. When there are multiple events >> with same name, 'perf record' will record all of them (in line with >> other tools supporting SDT (systemtap)). >> >> I know 'perf probe' for SDT events has already became interface and >> people are using it. But, doing this change will make user interface very >> easy and also it will make tool behaviour consistent. Also, it won't >> require any changes in uprobe_events structure (suggested by Masami[2]). > So I like the automatism you implemented for 'perf record', but why not keep the > 'perf probe' flow as well, if people got used to it? > > It's not like computer software is bad at sorting apart and handling the two cases > properly, right? Thanks Ingo for the reply, Yes, initially I thought about allowing both, 'perf probe' and 'perf record' for SDT event. But there are few complications with it, esp. when multiple SDT events with same name exists. For ex, $ readelf -n /usr/lib64/libpthread-2.24.so | grep -A2 Provider Provider: libpthread Name: mutex_entry Location: 0x0000000000009ddb, ... -- Provider: libpthread Name: mutex_entry Location: 0x000000000000bcbb, ... At the time of record, perf has to check first if there is any matching entry exists in uprobe_events with that name. If found, record it, if not, go look into probe cache. If events exists with same name in probe cache, record all of them. Like, If probe point _is not_ created, $ perf record -a -e sdt_libpthread:mutex_entry /** Record both sdt_libpthread:mutex_entry **/ If probe point _is_ created manually, record that particular event, $ perf probe -x /usr/lib64/libpthread-2.24.so sdt_libpthread:mutex_entry Added new events: sdt_libpthread:mutex_entry (on %mutex_entry in /usr/lib64/libpthread-2.24.so) sdt_libpthread:mutex_entry_1 (on %mutex_entry in /usr/lib64/libpthread-2.24.so) $ perf record -a -e sdt_libpthread:mutex_entry /** Record only first sdt_libpthread:mutex_entry **/ Here, same command gives different behaviour for different scenarios. Now consider a scenario when probe point exists for any one event: $ perf probe -d sdt_libpthread:mutex_entry_1 $ perf probe --list sdt_libpthread:mutex_entry (on pthread_mutex_lock+11 in /usr/lib64/libpthread-2.24.so) And user tries to record it by, $ perf record -a -e sdt_libpthread:* 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. 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. -Ravi