Received: by 10.223.185.116 with SMTP id b49csp6251186wrg; Wed, 28 Feb 2018 06:28:39 -0800 (PST) X-Google-Smtp-Source: AH8x226ssnUTPq3KNYlGXqGYl8sSEJeX1iOaeeoBwd36Py28CniOJg5raU3Y2jQcas/MI9ewmJ4q X-Received: by 10.98.196.199 with SMTP id h68mr17792630pfk.42.1519828119257; Wed, 28 Feb 2018 06:28:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519828119; cv=none; d=google.com; s=arc-20160816; b=Yp+ZArzVPCWygCGtZ0Tq0N5o4DrvbxDy+yya9IP8h0NSbwxmgbFjrlcuIGzfQhgNPf JjwncjMgO2D3HJ8CtPpv/enMD94KpY82pw1zaJRAjxT6JMWhEBQ4kU0QRfkc4P9HqI05 /C8F8s+LafW3DpqrcMIJWcDHo9uCl2J+gqsmUylHrZ5WlnMxkKohTuG/BwyY/Fvikpbj oCyDXzz+uBTcfNa2WKzCFRl1Sf4U9XNGkzdDWoKFQIg8EuYs15gYoaRI7jhFQI968H7Q iJDo7ITC/Y+uWcmiwZ0n9dUr3soDNXUu6bnXz5+PDb77fB8SY60YMscvX7O+mD8m13mt CC2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=gr1Jp76vVHWyoG4PasoJiwf54RtIbMbINBUST9UwKNk=; b=PJS98EtET5R/2rxTslD5HYi35hKY98s6AhcmkIeAbZpOKXPh2qJbICa/QYJ1FWx3jM fE47eInKboCFy53lySwzeQor90ZoHYzDmzUjcDe5iKgy2KLrecVqN5i0ud+QdW3XZxew /vyI6KHAc2oiL6PbV17Bkw14EfUkHAzQ473VmxpRSilw81t0ELFiKHsBSzuchadOR9xT 1u2XIwkpzJ2Rx14db/iGoBb1RsuDZDxPZrS/Gb06gX8ur3skjH2RcwZnXOcgpp7PhjUn ruW9RY9B3eMkrazXwnZ54vQK+RBnPd9320HZCslZ8j1p+Y/yWcgwbDaBp0h1n/dNjVlL wBPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j88si1309675pfe.324.2018.02.28.06.28.24; Wed, 28 Feb 2018 06:28:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752499AbeB1OZ5 (ORCPT + 99 others); Wed, 28 Feb 2018 09:25:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:41626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241AbeB1OZ4 (ORCPT ); Wed, 28 Feb 2018 09:25:56 -0500 Received: from devbox (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AE91B21782; Wed, 28 Feb 2018 14:25:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE91B21782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mhiramat@kernel.org Date: Wed, 28 Feb 2018 23:25:51 +0900 From: Masami Hiramatsu To: Ravi Bangoria Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, ananth@linux.vnet.ibm.com, naveen.n.rao@linux.vnet.ibm.com, srikar@linux.vnet.ibm.com, oleg@redhat.com Subject: Re: [RFC 0/4] trace_uprobe: Support SDT markers having semaphore Message-Id: <20180228232551.5e99736b4b4fd209e492cd4d@kernel.org> In-Reply-To: <20180228075345.674-1-ravi.bangoria@linux.vnet.ibm.com> References: <20180228075345.674-1-ravi.bangoria@linux.vnet.ibm.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ravi, Thank you for your great work! On Wed, 28 Feb 2018 13:23:41 +0530 Ravi Bangoria wrote: > Userspace Statically Defined Tracepoints[1] are dtrace style markers > inside userspace applications. These markers are added by developer at > important places in the code. Each marker source expands to a single > nop instruction in the compiled code but there may be additional > overhead for computing the marker arguments which expands to couple of > instructions. If this computaion is quite more, execution of it can be > ommited by runtime if() condition when no one is tracing on the marker: > > if (semaphore > 0) { > Execute marker instructions; > } > > Default value of semaphore is 0. Tracer has to increment the semaphore > before recording on a marker and decrement it at the end of tracing. > > Currently, perf tool has limited supports for SDT markers. I.e. it > can not trace markers surrounded by semaphore. Also, it's not easy > to add semaphore flip logic in userspace tool like perf, so basic > idea for this patchset is to add semaphore flip logic in the > trace_uprobe infrastructure. Ex,[2] > > # cat tick.c > ... > for (i = 0; i < 100; i++) { > DTRACE_PROBE1(tick, loop1, i); > if (TICK_LOOP2_ENABLED()) { > DTRACE_PROBE1(tick, loop2, i); > } > printf("hi: %d\n", i); > sleep(1); > } > ... > > Here tick:loop1 is marker without semaphore where as tick:loop2 is > surrounded by semaphore. > > > # perf buildid-cache --add /tmp/tick > # perf probe sdt_tick:loop1 > # perf probe sdt_tick:loop2 > > # perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick > hi: 0 > hi: 1 > hi: 2 > ^C > Performance counter stats for '/tmp/tick': > 3 sdt_tick:loop1 > 0 sdt_tick:loop2 > 2.747086086 seconds time elapsed > > > Perf failed to record data for tick:loop2. Same experiment with this > patch series: > > > # readelf -n ./tick > Provider: tick > Name: loop2 > ... Semaphore: 0x0000000010020036 > > # readelf -SW ./tick | grep probes > [25] .probes PROGBITS 0000000010020034 010034 > > > Semaphore offset is 0x10036. I don't have educated 'perf probe' > about semaphore. So instead of using 'perf probe' command, I'm > manually adding entry in the /uprobe_events file. Ok, it is easy to pass semaphore address via perf probe :) > Special char * denotes semaphore offset. > > > # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4 *0x10036" > uprobe_events IMHO, this syntax is no good, separate with space is only for arguments. Since the semaphore is per-probe-point based, that should be specified with probe point. (there are no 2 or more semaphores on 1 event, are there?) So something like # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4(0x10036)" > uprobe_events would be better to me. Thank you, > > # perf stat -e sdt_tick:loop2 -- /tmp/tick > hi: 0 > hi: 1 > hi: 2 > hi: 3 > ^C > Performance counter stats for '/tmp/tick': > 4 sdt_tick:loop2 > 3.359047827 seconds time elapsed > > > Feedback? > > TODO: > - Educate perf tool about semaphore. > - perf_event_open() now suppoers {k,u}probe event creation[3]. If we > can supply semaphore offset in perf_event_attr, perf_event_open() > can be educated to probe SDT marker having semaphore. Though, both > config1 and config2 are already being used for uprobe and I don't > see any other attribute which I can use for semaphore offset. Can > we introduce one more config there? config3? > > [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation > [2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506 > [3] https://lkml.org/lkml/2017/12/6/976 > > > Ravi Bangoria (4): > Uprobe: Rename map_info to uprobe_map_info > Uprobe: Export few functions / data structures > trace_uprobe: Support SDT markers having semaphore > trace_uprobe: Fix multiple update of same semaphores > > include/linux/uprobes.h | 25 +++++ > kernel/events/uprobes.c | 43 ++++---- > kernel/trace/trace_uprobe.c | 244 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 290 insertions(+), 22 deletions(-) > > -- > 1.8.3.1 > -- Masami Hiramatsu