From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352AbdAXIgk (ORCPT ); Tue, 24 Jan 2017 03:36:40 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53243 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbdAXIgh (ORCPT ); Tue, 24 Jan 2017 03:36:37 -0500 Subject: Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string To: Ingo Molnar References: <20161207122610.008da636793d38a39accf29b@kernel.org> <20161214000732.1710-1-alexis.berlemont@gmail.com> <20161214073656.GB1635@gmail.com> <5886FB0B.40901@linux.vnet.ibm.com> <20170124082225.GC8667@gmail.com> Cc: Alexis Berlemont , linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, Jiri Olsa , Ravi Bangoria , Hemant Kumar From: Ravi Bangoria Date: Tue, 24 Jan 2017 14:06:22 +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: <20170124082225.GC8667@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: 17012408-8235-0000-0000-00000AC87653 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006488; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000200; SDB=6.00811917; UDB=6.00395905; IPR=6.00589334; BA=6.00005084; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014022; XFM=3.00000011; UTC=2017-01-24 08:36:29 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17012408-8236-0000-0000-000038FDC374 Message-Id: <58871206.1080908@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-24_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701240073 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 24 January 2017 01:52 PM, Ingo Molnar wrote: > * Ravi Bangoria wrote: > >> >> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote: >>> * Alexis Berlemont wrote: >>> >>>> Hi Masami, >>>> >>>> Many thanks for your mail. >>>> >>>> Here is another patch set which tries to fix the points you mentioned: >>>> >>>> * Skip the arguments containing a constant ($123); >>>> * Review the code in charge of the register renaming (search for '%' >>>> and parse it); >>>> * Minor changes (print the argument in case of error, skipping, check >>>> the sdt arg type index); >>>> >>>> Many thanks, >>>> >>>> Alexis. >>>> >>>> Alexis Berlemont (2): >>>> perf sdt: add scanning of sdt probles arguments >>>> perf probe: add sdt probes arguments into the uprobe cmd string >>> I'd like to hijack this thread to report an SDT oddity - one of my boxen reports >>> lots of SDT tracepoints in 'perf list': >>> >>> mem:[/len][:access] [Hardware breakpoint] >>> >>> sdt_libc:lll_lock_wait_private [SDT event] >>> sdt_libc:longjmp [SDT event] >>> sdt_libc:longjmp_target [SDT event] >>> sdt_libc:memory_arena_new [SDT event] >>> sdt_libc:memory_arena_retry [SDT event] >>> sdt_libc:memory_arena_reuse [SDT event] >>> sdt_libc:memory_arena_reuse_free_list [SDT event] >>> sdt_libc:memory_arena_reuse_wait [SDT event] >>> sdt_libc:memory_calloc_retry [SDT event] >>> sdt_libc:memory_heap_free [SDT event] >>> ... >>> >>> But none of them work: >>> >>> Error: No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp >>> Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing' >>> >>> ... >>> >>> Error: File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found. >>> Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?. >>> >>> What kind of patches are required for SDT probes to work? >> Hi Ingo, >> >> I suppose you are trying to record SDT events without probing it. >> In that case, first put a probe on an event and then try to record >> it. For example, > > Well, I was mainly complaining about the misleading messages and flow of the > tooling here. Could you please improve the messages so that if I use it like the > way I reported it results in me trying the right approach? Right, message is misleading. Will prepare a patch for this. Also it's little odd flow for sdt markers, to put a probe first and then record it while other events can be recorded directly. There was a patch by Hemant about directly recording SDT marker events. I don't see any updates on that: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1138183.html -Ravi > Thanks, > > Ingo >