Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752604AbdCALBN (ORCPT ); Wed, 1 Mar 2017 06:01:13 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37918 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752416AbdCAK7v (ORCPT ); Wed, 1 Mar 2017 05:59:51 -0500 Subject: Re: [PATCH v3 2/2] perf/sdt: Directly record SDT events with 'perf record' To: Brendan Gregg References: <20170224074325.2451-1-ravi.bangoria@linux.vnet.ibm.com> <20170224074325.2451-3-ravi.bangoria@linux.vnet.ibm.com> Cc: Ingo Molnar , Arnaldo Carvalho de Melo , Peter Zijlstra , Alexander Shishkin , Wang Nan , Jiri Olsa , Andi Kleen , treeze.taeung@gmail.com, Mathieu Poirier , He Kuang , sukadev@linux.vnet.ibm.com, ananth@in.ibm.com, "Naveen N. Rao" , Adrian Hunter , LKML , Hemant Kumar , Masami Hiramatsu , Ravi Bangoria From: Ravi Bangoria Date: Wed, 1 Mar 2017 11:15:36 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17030105-0020-0000-0000-00000B84776A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006701; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000205; SDB=6.00828416; UDB=6.00406021; IPR=6.00605933; BA=6.00005175; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014480; XFM=3.00000011; UTC=2017-03-01 05:45:53 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17030105-0021-0000-0000-00005A87EBAF Message-Id: <58B66000.7080504@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-01_02:,, 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-1703010056 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5290 Lines: 149 Thank you Brendan for reviewing, On Wednesday 01 March 2017 10:34 AM, Brendan Gregg wrote: > On Tue, Feb 28, 2017 at 2:31 PM, Brendan Gregg > wrote: >> G'Day Ravi, >> > [...] >> Now retrying perf: >> >> # ./perf record -e sdt_node:http__server__request -a >> ^C[ perf record: Woken up 1 times to write data ] >> [ perf record: Captured and wrote 0.446 MB perf.data (3 samples) ] >> # ./perf script >> node 7646 [002] 361.012364: >> sdt_node:http__server__request: (dc2e69) >> node 7646 [002] 361.204718: >> sdt_node:http__server__request: (dc2e69) >> node 7646 [002] 361.363043: >> sdt_node:http__server__request: (dc2e69) >> >> Now perf works. >> >> If I restart the node process, it goes back to the broken state. >> > Oh sorry, I forgot about that these Node.js probes are behind an > is-enabled semaphore. Yes. Perf does not support "is-enabled" markers yet. > $ readelf -n `which node` > [...] > stapsdt 0x00000089 NT_STAPSDT (SystemTap probe descriptors) > Provider: node > Name: http__server__request > Location: 0x0000000000dc2e69, Base: 0x000000000112e064, Semaphore: > 0x0000000001470954 > Arguments: 8@%r14 8@%rax 8@-4344(%rbp) -4@-4348(%rbp) > 8@-4304(%rbp) 8@-4312(%rbp) -4@-4352(%rbp) > # dd if=/proc/31695/mem bs=1 count=1 skip=$(( 0x0000000001470954 )) > 2>/dev/null | xxd > 00000000: 00 . > # printf "\x1" | dd of=/proc/31695/mem bs=1 count=1 seek=$(( > 0x0000000001470954 )) 2>/dev/null > # dd if=/proc/31695/mem bs=1 count=1 skip=$(( 0x0000000001470954 )) > 2>/dev/null | xxd > 00000000: 01 . > # ./perf record -e sdt_node:http__server__request -a > Matching event(s) from uprobe_events: > sdt_node:http__server__request 0x9c2e69@/usr/local/bin/node > Use 'perf probe -d ' to delete event(s). > ^C[ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.280 MB perf.data (3 samples) ] > # ./perf script > node 31695 [003] 24947.168761: > sdt_node:http__server__request: (dc2e69) > node 31695 [003] 24947.476143: > sdt_node:http__server__request: (dc2e69) > node 31695 [003] 24947.679090: > sdt_node:http__server__request: (dc2e69) > > So setting that to 1 made the probe work from perf. I guess this is > not a problem with this patch set, but rather a feature request for > the next one: is-enabled SDT support. Yes. Actually I'm thinking about how this can be accomplished. Perf is a userspace tool and, unlike systemtap, it cannot change semaphore value easily. This is what I was thinking: 'perf record', at the start of session will increments semaphore in /proc//mem. and at the end of session, perf will decrement it (same as bcc). This does not require any support from kernel infrastructure. But there are challenges with this approach: 1. What if user starts workload after starting 'perf record'. How perf will be able to increment semaphore value. 2. Systemwide record. We have to loop over all pids and check if any process is using SDT with semaphore that is being recorded. 3. Dynamic library loading. How to handle SDT probes in library that is not loaded at the time of 'perf record'? Please let me know your thoughts. > Were probe arguments supposed to work? I don't notice them in the perf > script output. Not yet. Alexis[1] (and followed by me[2]) had sent patches for that. Please have a look at them. [1] https://lkml.org/lkml/2016/12/13/784 [2] https://lkml.org/lkml/2017/2/2/145 So, why perf is able to record data after recording them with bcc? Ideally, bcc should increment semaphore value at the start of session and it should decrement at the end of the session. So after bcc process exits, semaphore value should be zero. But actually it's not happening. I've seen this when I was experimenting bcc with is-enabled markers. See this example, $ readelf -n /usr/bin/node | grep -A2 Provider Provider: node Name: http__server__request Location: 0x0000000000e5f484, Base: 0x00000000011a0bc4, Semaphore: 0x0000000001558cf2 $ sudo cat /proc/1426/maps 00400000-01306000 r-xp 00000000 08:02 1083365 /usr/bin/node 01506000-01551000 r--p 00f06000 08:02 1083365 /usr/bin/node 01551000-01559000 rw-p 00f51000 08:02 1083365 /usr/bin/node ... [TERMINAL-1]$ gdb 1426 (gdb) x/1 0x1558cf2 0x1558cf2: 0 [TERMINAL-2]$ sudo ./trace.py -p 1426 'u:node:http__server__request' PID TID COMM FUNC /* Do not exit yet. */ [TERMINAL-1] (gdb) x/1 0x1558cf2 0x1558cf2: 2 [TERMINAL-2] ^C /* Exit bcc trace.py */ [TERMINAL-1] (gdb) x/1 0x1558cf2 0x1558cf2: 2 Here it's maintaining value 2 as it is. it should be 0. I suspect this is a bug in bcc. Please let me know if I'm understanding it wrong. > > PS, if it's helpful, here's the commands to build node with these SDT probes: > > $ sudo apt-get install systemtap-sdt-dev # adds "dtrace", used > by node build > $ wget https://nodejs.org/dist/v4.4.1/node-v4.4.1.tar.gz > $ tar xvf node-v4.4.1.tar.gz > $ cd node-v4.4.1 > $ ./configure --with-dtrace > $ make -j 8 Thanks for this. :) -Ravi