Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial implementation of DTrace

On Wed, Jul 10, 2019 at 2:36 PM Kris Van Hees wrote: > > On Wed, Jul 10, 2019 at 11:19:43PM +0200, Daniel Borkmann wrote: > > On 07/10/2019 10:30 PM, Jonathan Corbet wrote: > > > On Wed, 10 Jul 2019 21:32:25 +0200 > > > Daniel Borkmann wrote: > > > > > >> Looks like you missed Brendan Gregg's

Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial implementation of DTrace

On Wed, Jul 10, 2019 at 1:30 PM Jonathan Corbet wrote: > > On Wed, 10 Jul 2019 21:32:25 +0200 > Daniel Borkmann wrote: > > > Looks like you missed Brendan Gregg's prior feedback from v1 [0]. I haven't > > seen a strong compelling argument for why this needs to reside in the kernel > > tree given

Re: [PATCH 1/1] tools/dtrace: initial implementation of DTrace

On Wed, Jul 3, 2019 at 8:17 PM Kris Van Hees wrote: > > This initial implementation of a tiny subset of DTrace functionality > provides the following options: > > dtrace [-lvV] [-b bufsz] -s script > -b set trace buffer size > -l list probes (only works with '-s

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Sat, Dec 30, 2017 at 7:06 PM, Yafang Shao <laoar.s...@gmail.com> wrote: > On Sun, Dec 31, 2017 at 6:33 AM, Brendan Gregg > <brendan.d.gr...@gmail.com> wrote: >> On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao <laoar.s...@gmail.com> wrote: >>> As sk_stat

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Sat, Dec 30, 2017 at 7:06 PM, Yafang Shao wrote: > On Sun, Dec 31, 2017 at 6:33 AM, Brendan Gregg > wrote: >> On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: >>> As sk_state is a common field for struct sock, so the state >>> transition tracepoint should

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: > As sk_state is a common field for struct sock, so the state > transition tracepoint should not be a TCP specific feature. > Currently it traces all AF_INET state transition, so I rename this > tracepoint to

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: > As sk_state is a common field for struct sock, so the state > transition tracepoint should not be a TCP specific feature. > Currently it traces all AF_INET state transition, so I rename this > tracepoint to inet_sock_set_state tracepoint with

[tip:perf/core] perf sched timehist: Add --next option

Commit-ID: 292c4a8f985b35b3738d5900fe256c4fed4cd3f5 Gitweb: http://git.kernel.org/tip/292c4a8f985b35b3738d5900fe256c4fed4cd3f5 Author: Brendan Gregg <bgr...@netflix.com> AuthorDate: Tue, 14 Mar 2017 01:56:29 + Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/core] perf sched timehist: Add --next option

Commit-ID: 292c4a8f985b35b3738d5900fe256c4fed4cd3f5 Gitweb: http://git.kernel.org/tip/292c4a8f985b35b3738d5900fe256c4fed4cd3f5 Author: Brendan Gregg AuthorDate: Tue, 14 Mar 2017 01:56:29 + Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 14 Mar 2017 15:17:38 -0300 perf sched

Re: [PATCH] perf sched timehist: Add --next option

On Tue, Mar 14, 2017 at 6:12 AM, Arnaldo Carvalho de Melo <a...@kernel.org> wrote: > Em Tue, Mar 14, 2017 at 01:56:29AM +, Brendan Gregg escreveu: >> The --next option shows the next task for each context switch, providing >> more context for the sequence of scheduler

Re: [PATCH] perf sched timehist: Add --next option

On Tue, Mar 14, 2017 at 6:12 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 14, 2017 at 01:56:29AM +0000, Brendan Gregg escreveu: >> The --next option shows the next task for each context switch, providing >> more context for the sequence of scheduler events. >> >> $

[PATCH] perf sched timehist: Add --next option

] Signed-off-by: Brendan Gregg <bgr...@netflix.com> --- tools/perf/Documentation/perf-sched.txt | 4 tools/perf/builtin-sched.c | 29 - 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/tools/perf/Documentation/perf-sched.txt b/tool

[PATCH] perf sched timehist: Add --next option

] Signed-off-by: Brendan Gregg --- tools/perf/Documentation/perf-sched.txt | 4 tools/perf/builtin-sched.c | 29 - 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/tools/perf/Documentation/perf-sched.txt b/tools/perf/Documentation/perf

Re: [PATCH v3 2/2] perf/sdt: Directly record SDT events with 'perf record'

On Tue, Feb 28, 2017 at 2:31 PM, Brendan Gregg <brendan.d.gr...@gmail.com> 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

Re: [PATCH v3 2/2] perf/sdt: Directly record SDT events with 'perf record'

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

Re: [PATCH v3 2/2] perf/sdt: Directly record SDT events with 'perf record'

G'Day Ravi, On Thu, Feb 23, 2017 at 11:43 PM, Ravi Bangoria wrote: > > From: Hemant Kumar > > Add support for directly recording SDT events which are present in > the probe cache. Without this patch, we could probe into SDT events >

Re: [PATCH v3 2/2] perf/sdt: Directly record SDT events with 'perf record'

G'Day Ravi, On Thu, Feb 23, 2017 at 11:43 PM, Ravi Bangoria wrote: > > From: Hemant Kumar > > Add support for directly recording SDT events which are present in > the probe cache. Without this patch, we could probe into SDT events > using 'perf probe' and 'perf record'. With this patch, we can

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

On Tue, Jan 3, 2017 at 2:47 PM, Brendan Gregg <brendan.d.gr...@gmail.com> wrote: > > On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann <a...@arndb.de> wrote: > > > > With arm-linux-gcc-4.2, almost every file we build in the kernel ends > > up with this warn

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

On Tue, Jan 3, 2017 at 2:47 PM, Brendan Gregg wrote: > > On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann wrote: > > > > With arm-linux-gcc-4.2, almost every file we build in the kernel ends > > up with this warning: > > > > include/linux/fs.h:2648: warning: c

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann wrote: > > With arm-linux-gcc-4.2, almost every file we build in the kernel ends > up with this warning: > > include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is > always false > Thanks, I'd like to see this

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann wrote: > > With arm-linux-gcc-4.2, almost every file we build in the kernel ends > up with this warning: > > include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is > always false > Thanks, I'd like to see this fixed as a similar

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot wrote: > > find_idlest_group() only compares the runnable_load_avg when looking for > the least loaded group. But on fork intensive use case like hackbench > where tasks blocked quickly after the fork, this can lead to

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot wrote: > > find_idlest_group() only compares the runnable_load_avg when looking for > the least loaded group. But on fork intensive use case like hackbench > where tasks blocked quickly after the fork, this can lead to selecting the > same CPU

Re: [PATCH v2 net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

by Peter and Daniel. Thanks Alexei! Tested-by: Brendan Gregg <bgr...@netflix.com> Brendan

Re: [PATCH v2 net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

at we discussed. > > Patches 1-3 is bpf-side prep for the main patch 4 > that adds bpf program as an overflow_handler to sw and hw perf_events. > Peter, please review. > > Patches 5 and 6 are examples from myself and Brendan. > > v1-v2: fixed issues spotted by Peter and Daniel. T

Re: [PATCH net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

On Mon, Aug 29, 2016 at 5:19 AM, Peter Zijlstra wrote: > > On Fri, Aug 26, 2016 at 07:31:18PM -0700, Alexei Starovoitov wrote: > > Hi Peter, Dave, > > > > this patch set is a follow up to the discussion: > > https://lkml.org/lkml/2016/8/4/304 > > It turned out to be simpler

Re: [PATCH net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

On Mon, Aug 29, 2016 at 5:19 AM, Peter Zijlstra wrote: > > On Fri, Aug 26, 2016 at 07:31:18PM -0700, Alexei Starovoitov wrote: > > Hi Peter, Dave, > > > > this patch set is a follow up to the discussion: > > https://lkml.org/lkml/2016/8/4/304 > > It turned out to be simpler than what we

[tip:perf/urgent] perf script: Add 'bpf-output' field to usage message

Commit-ID: bcdc09af3ef30ef071677544ce23a1c8873a2dda Gitweb: http://git.kernel.org/tip/bcdc09af3ef30ef071677544ce23a1c8873a2dda Author: Brendan Gregg <bgr...@netflix.com> AuthorDate: Wed, 3 Aug 2016 02:47:49 + Committer: Arnaldo Carvalho de Melo <a...@redhat.com> Commit

[tip:perf/urgent] perf script: Add 'bpf-output' field to usage message

Commit-ID: bcdc09af3ef30ef071677544ce23a1c8873a2dda Gitweb: http://git.kernel.org/tip/bcdc09af3ef30ef071677544ce23a1c8873a2dda Author: Brendan Gregg AuthorDate: Wed, 3 Aug 2016 02:47:49 + Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 9 Aug 2016 10:46:43 -0300 perf script

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 5, 2016 at 3:52 AM, Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: >> tracepoints are actually zero overhead already via static-key mechanism. >> I don't think Peter's objection for the tracepoint was due to overhead.

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 5, 2016 at 3:52 AM, Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 10:24:06PM -0700, Alexei Starovoitov wrote: >> tracepoints are actually zero overhead already via static-key mechanism. >> I don't think Peter's objection for the tracepoint was due to overhead. > > Almost 0, they

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: >> >> > As for pmu tracepoints: if I were to in

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov wrote: > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: >> >> > As for pmu tracepoints: if I were to instrument it (although I wasn't &g

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 3, 2016 at 2:48 AM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Wed, Aug 03, 2016 at 02:47:47AM +0000, Brendan Gregg wrote: > > When perf is performing hrtimer-based sampling, this tracepoint can be used > > by BPF to run additional logic on each samp

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Wed, Aug 3, 2016 at 2:48 AM, Peter Zijlstra wrote: > > On Wed, Aug 03, 2016 at 02:47:47AM +, Brendan Gregg wrote: > > When perf is performing hrtimer-based sampling, this tracepoint can be used > > by BPF to run additional logic on each sample. For example, BPF can fetc

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F) <wangn...@huawei.com> wrote: > > > On 2016/7/30 2:05, Brendan Gregg wrote: >> >> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg <bgr...@netflix.com> wrote: >>> >>> When perf is performing hrti

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F) wrote: > > > On 2016/7/30 2:05, Brendan Gregg wrote: >> >> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg wrote: >>> >>> When perf is performing hrtimer-based sampling, this tracepoint can be >>> used &

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

), default 99 duration # sampling duration (seconds), default 5 Signed-off-by: Brendan Gregg <bgr...@netflix.com> Cc: Alexei Starovoitov <a...@kernel.org> Cc: Wang Nan <wangn...@huawei.com> --- samples/bpf/Makefile| 4 + samples/bpf/sampleip_kern.c | 48 ++

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

), default 99 duration # sampling duration (seconds), default 5 Signed-off-by: Brendan Gregg Cc: Alexei Starovoitov Cc: Wang Nan --- samples/bpf/Makefile| 4 + samples/bpf/sampleip_kern.c | 48 +++ samples/bpf/sampleip_user.c | 189

[PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

When perf is performing hrtimer-based sampling, this tracepoint can be used by BPF to run additional logic on each sample. For example, BPF can fetch stack traces and frequency count them in kernel context, for an efficient profiler. Signed-off-by: Brendan Gregg <bgr...@netflix.com> Cc:

[PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

When perf is performing hrtimer-based sampling, this tracepoint can be used by BPF to run additional logic on each sample. For example, BPF can fetch stack traces and frequency count them in kernel context, for an efficient profiler. Signed-off-by: Brendan Gregg Cc: Alexei Starovoitov Cc: Wang

[PATCH v2 3/3] perf script: add bpf-output field to usage message

This adds the bpf-output field to the perf script usage message, and docs. Signed-off-by: Brendan Gregg <bgr...@netflix.com> Cc: Wang Nan <wangn...@huawei.com> --- tools/perf/Documentation/perf-script.txt | 4 ++-- tools/perf/builtin-script.c | 2 +- 2 files changed,

[PATCH v2 0/3] Add a tracepoint for BPF perf sampling

This patchset adds a tracepoint for perf sampling, perf:perf_hrtimer, and includes a complete example in samples/bpf for using it to frequency count sampled instruction pointers in a BPF map. Signed-off-by: Brendan Gregg <bgr...@netflix.com> --- Changes in v2: - added samples/bpf/sa

[PATCH v2 3/3] perf script: add bpf-output field to usage message

This adds the bpf-output field to the perf script usage message, and docs. Signed-off-by: Brendan Gregg Cc: Wang Nan --- tools/perf/Documentation/perf-script.txt | 4 ++-- tools/perf/builtin-script.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf

[PATCH v2 0/3] Add a tracepoint for BPF perf sampling

This patchset adds a tracepoint for perf sampling, perf:perf_hrtimer, and includes a complete example in samples/bpf for using it to frequency count sampled instruction pointers in a BPF map. Signed-off-by: Brendan Gregg --- Changes in v2: - added samples/bpf/sampleip* example

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 12:21 PM, Arnaldo Carvalho de Melo <a...@kernel.org> wrote: > Em Tue, Jul 19, 2016 at 11:20:48PM +, Brendan Gregg escreveu: >> When perf is performing hrtimer-based sampling, this tracepoint can be used >> by BPF to run additional logic on each sam

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 12:21 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 19, 2016 at 11:20:48PM +0000, Brendan Gregg escreveu: >> When perf is performing hrtimer-based sampling, this tracepoint can be used >> by BPF to run additional logic on each sample. For example

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg <bgr...@netflix.com> wrote: > When perf is performing hrtimer-based sampling, this tracepoint can be used > by BPF to run additional logic on each sample. For example, BPF can fetch > stack traces and frequency count them in

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg wrote: > When perf is performing hrtimer-based sampling, this tracepoint can be used > by BPF to run additional logic on each sample. For example, BPF can fetch > stack traces and frequency count them in kernel context, for an efficient &

[PATCH] perf/core: Add a tracepoint for perf sampling

When perf is performing hrtimer-based sampling, this tracepoint can be used by BPF to run additional logic on each sample. For example, BPF can fetch stack traces and frequency count them in kernel context, for an efficient profiler. Signed-off-by: Brendan Gregg <bgr...@netflix.com> Cc:

[PATCH] perf/core: Add a tracepoint for perf sampling

When perf is performing hrtimer-based sampling, this tracepoint can be used by BPF to run additional logic on each sample. For example, BPF can fetch stack traces and frequency count them in kernel context, for an efficient profiler. Signed-off-by: Brendan Gregg Cc: Alexei Starovoitov Cc: Wang

Re: perf bpf examples

On Fri, Jul 8, 2016 at 3:46 AM, Wangnan (F) <wangn...@huawei.com> wrote: > > > On 2016/7/8 15:57, Brendan Gregg wrote: >> [...] >> I mean just an -F99 that executes a BPF program on each sample. My >> most common use for perf is: >> >> perf record -F

Re: perf bpf examples

On Fri, Jul 8, 2016 at 3:46 AM, Wangnan (F) wrote: > > > On 2016/7/8 15:57, Brendan Gregg wrote: >> [...] >> I mean just an -F99 that executes a BPF program on each sample. My >> most common use for perf is: >> >> perf record -F 99 -a -g -- sleep 30 >

Re: perf bpf examples

On Thu, Jul 7, 2016 at 9:18 PM, Wangnan (F) <wangn...@huawei.com> wrote: > > > On 2016/7/8 1:58, Brendan Gregg wrote: >> >> On Thu, Jul 7, 2016 at 10:54 AM, Brendan Gregg >> <brendan.d.gr...@gmail.com> wrote: >>> >>> On Wed, Jul 6,

Re: perf bpf examples

On Thu, Jul 7, 2016 at 9:18 PM, Wangnan (F) wrote: > > > On 2016/7/8 1:58, Brendan Gregg wrote: >> >> On Thu, Jul 7, 2016 at 10:54 AM, Brendan Gregg >> wrote: >>> >>> On Wed, Jul 6, 2016 at 6:49 PM, Wangnan (F) wrote: [...] >> ... Also, has an

Re: [PATCH perf/core v12 00/16] perf-probe --cache and SDT support

On Fri, Jun 24, 2016 at 2:05 AM, Masami Hiramatsu wrote: > Hi, > > Here is the 12th version of the patchset for probe-cache and > initial SDT support. > > Here is the previous v11: https://lkml.org/lkml/2016/6/14/1041 > > In this version I just rename strlist__for_each to >

Re: [PATCH perf/core v12 00/16] perf-probe --cache and SDT support

On Fri, Jun 24, 2016 at 2:05 AM, Masami Hiramatsu wrote: > Hi, > > Here is the 12th version of the patchset for probe-cache and > initial SDT support. > > Here is the previous v11: https://lkml.org/lkml/2016/6/14/1041 > > In this version I just rename strlist__for_each to >

Re: [PATCH 10/10] perf script: Add stackcollapse.py script

gt; stacks directly, obviating the need for stackcollapse-perf.pl", so here > it is. > > This script is a Python rewrite of stackcollapse-perf.pl, using the perf > scripting interface to access the perf data directly from Python. > > Signed-off-by: Paolo Bonzini <pbo

Re: [PATCH 10/10] perf script: Add stackcollapse.py script

the need for stackcollapse-perf.pl", so here > it is. > > This script is a Python rewrite of stackcollapse-perf.pl, using the perf > scripting interface to access the perf data directly from Python. > > Signed-off-by: Paolo Bonzini > Acked-by: Jiri Olsa > Cc: Brendan Gregg &

Re: [GIT PULL 00/10] perf/core improvements and fixes

> > Bonzini) > > I think this is already done by '-g folded'. Please see: > > http://www.brendangregg.com/blog/2016-04-30/linux-perf-folded.html > Pretty much. Two similar solutions were developed around the same time. Although I have to use some awk to get "perf -g folded" in the exact right format, and stackcollapse-perf.py does that directly. Brendan Brendan Gregg, Senior Performance Architect, Netflix

Re: [GIT PULL 00/10] perf/core improvements and fixes

; > I think this is already done by '-g folded'. Please see: > > http://www.brendangregg.com/blog/2016-04-30/linux-perf-folded.html > Pretty much. Two similar solutions were developed around the same time. Although I have to use some awk to get "perf -g folded" in the exact right format, and stackcollapse-perf.py does that directly. Brendan Brendan Gregg, Senior Performance Architect, Netflix

Re: BPF runtime for systemtap

On Tue, Jun 14, 2016 at 1:06 PM, Richard Henderson wrote: > I'm pleased to be able to announce an initial implementation of an (e)bpf > backend for systemtap. For the subset of systemtap probes that can use > kprobes, we can use a bpf filter instead of loading a kernel module. >

Re: BPF runtime for systemtap

On Tue, Jun 14, 2016 at 1:06 PM, Richard Henderson wrote: > I'm pleased to be able to announce an initial implementation of an (e)bpf > backend for systemtap. For the subset of systemtap probes that can use > kprobes, we can use a bpf filter instead of loading a kernel module. > > As this

Re: [PATCH] perf/sdt: Directly record cached SDT events

On Fri, Apr 29, 2016 at 6:40 AM, Hemant Kumar wrote: > This patch adds support for directly recording SDT events which are > present in the probe cache. This patch is based on current SDT > enablement patchset (v5) by Masami : > https://lkml.org/lkml/2016/4/27/828 > and

Re: [PATCH] perf/sdt: Directly record cached SDT events

On Fri, Apr 29, 2016 at 6:40 AM, Hemant Kumar wrote: > This patch adds support for directly recording SDT events which are > present in the probe cache. This patch is based on current SDT > enablement patchset (v5) by Masami : > https://lkml.org/lkml/2016/4/27/828 > and it implements two points

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Tue, Apr 26, 2016 at 2:05 PM, Arnaldo Carvalho de Melo <arnaldo.m...@gmail.com> wrote: > Em Tue, Apr 26, 2016 at 01:02:34PM -0700, Brendan Gregg escreveu: >> On Mon, Apr 25, 2016 at 5:49 PM, Brendan Gregg <brendan.d.gr...@gmail.com> >> wrote: >> > On M

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Tue, Apr 26, 2016 at 2:05 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Apr 26, 2016 at 01:02:34PM -0700, Brendan Gregg escreveu: >> On Mon, Apr 25, 2016 at 5:49 PM, Brendan Gregg >> wrote: >> > On Mon, Apr 25, 2016 at 5:47 PM, Arnaldo Carvalho de Melo >>

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Mon, Apr 25, 2016 at 5:49 PM, Brendan Gregg <brendan.d.gr...@gmail.com> wrote: > On Mon, Apr 25, 2016 at 5:47 PM, Arnaldo Carvalho de Melo > <arnaldo.m...@gmail.com> wrote: >> Em Mon, Apr 25, 2016 at 05:44:00PM -0700, Alexei Starovoitov escreveu: >>> On Mon,

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Mon, Apr 25, 2016 at 5:49 PM, Brendan Gregg wrote: > On Mon, Apr 25, 2016 at 5:47 PM, Arnaldo Carvalho de Melo > wrote: >> Em Mon, Apr 25, 2016 at 05:44:00PM -0700, Alexei Starovoitov escreveu: >>> On Mon, Apr 25, 2016 at 09:29:28PM -0300, Arnaldo Carvalho de Melo wrote:

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

> The rest looks good. Thanks! >> > >> > Something else? ;-) >> >> all looks good to me. Thanks a bunch! > > Thanks for checking! > >> > Because we only allocate the callchain percpu data structures when >> > there >> > is a user, which all

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

t;> > Something else? ;-) >> >> all looks good to me. Thanks a bunch! > > Thanks for checking! > >> > Because we only allocate the callchain percpu data structures when >> > there >> > is a user, which allows for changing the max eas

Re: [RFC] The Linux Scheduler: a Decade of Wasted Cores Report

On Sat, Apr 23, 2016 at 11:20 AM, Jeff Merkey wrote: > > Interesting read. > > http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf > > "... The Linux kernel scheduler has deficiencies that prevent a > multicore system from making proper use of all cores for heavily >

Re: [RFC] The Linux Scheduler: a Decade of Wasted Cores Report

On Sat, Apr 23, 2016 at 11:20 AM, Jeff Merkey wrote: > > Interesting read. > > http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf > > "... The Linux kernel scheduler has deficiencies that prevent a > multicore system from making proper use of all cores for heavily > multithreaded loads,

Re: [PATCHSET 0/9] perf report: Support folded callchain output (v5)

On Sun, Nov 8, 2015 at 9:45 PM, Namhyung Kim wrote: > Hello, > > This is what Brendan requested on the perf-users mailing list [1] to > support FlameGraphs [2] more efficiently. This patchset adds a few > more callchain options to adjust the output for it. > > * changes in v5) >- honor

Re: [PATCHSET 0/9] perf report: Support folded callchain output (v5)

On Sun, Nov 8, 2015 at 9:45 PM, Namhyung Kim wrote: > Hello, > > This is what Brendan requested on the perf-users mailing list [1] to > support FlameGraphs [2] more efficiently. This patchset adds a few > more callchain options to adjust the output for it. > > * changes in

Re: [PATCHSET 0/4] perf report: Support folded callchain output (v4)

On Tue, Nov 3, 2015 at 5:54 PM, Namhyung Kim wrote: > Hi Brendan, > > On Tue, Nov 03, 2015 at 01:33:43PM -0800, Brendan Gregg wrote: >> On Tue, Nov 3, 2015 at 6:40 AM, Arnaldo Carvalho de Melo >> wrote: >> > Em Tue, Nov 03, 2015 at 09:52:07PM +0900, Namh

Re: [PATCHSET 0/4] perf report: Support folded callchain output (v4)

On Tue, Nov 3, 2015 at 6:40 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 03, 2015 at 09:52:07PM +0900, Namhyung Kim escreveu: >> Hello, >> >> This is what Brendan requested on the perf-users mailing list [1] to >> support FlameGraphs [2] more efficiently. This patchset adds a few >> more

Re: [PATCHSET 0/4] perf report: Support folded callchain output (v4)

On Tue, Nov 3, 2015 at 6:40 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 03, 2015 at 09:52:07PM +0900, Namhyung Kim escreveu: >> Hello, >> >> This is what Brendan requested on the perf-users mailing list [1] to >> support FlameGraphs [2] more efficiently. This

Re: [PATCHSET 0/4] perf report: Support folded callchain output (v4)

On Tue, Nov 3, 2015 at 5:54 PM, Namhyung Kim <namhy...@kernel.org> wrote: > Hi Brendan, > > On Tue, Nov 03, 2015 at 01:33:43PM -0800, Brendan Gregg wrote: >> On Tue, Nov 3, 2015 at 6:40 AM, Arnaldo Carvalho de Melo >> <arnaldo.m...@gmail.com> wrote: >> >

Re: [RFC/PATCH 3/3] perf tools: Defaults to 'caller' callchain order only if --children is enabled

On Thu, Oct 22, 2015 at 7:03 AM, Arnaldo Carvalho de Melo wrote: > Em Thu, Oct 22, 2015 at 02:49:11AM -0700, Brendan Gregg escreveu: >> On Thu, Oct 22, 2015 at 12:38 AM, Namhyung Kim wrote: >> > Hi Ingo, >> > >> > On Thu, Oct 22, 2015 at 4:32 PM, Ingo Molna

Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

On Mon, Nov 2, 2015 at 2:12 PM, Namhyung Kim wrote: > Hi Arnaldo, > > On Mon, Nov 02, 2015 at 06:30:21PM -0300, Arnaldo Carvalho de Melo wrote: >> Em Mon, Nov 02, 2015 at 12:37:28PM -0800, Brendan Gregg escreveu: >> > G'Day Namhyung, >> > >> > On Mon, N

Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

G'Day Namhyung, On Mon, Nov 2, 2015 at 4:57 AM, Namhyung Kim wrote: > Hello, > > This is what Brendan requested on the perf-users mailing list [1] to > support FlameGraphs [2] more efficiently. This patchset adds a few > more callchain options to adjust the output for it. > > At first, 'folded'

Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

G'Day Namhyung, On Mon, Nov 2, 2015 at 4:57 AM, Namhyung Kim wrote: > Hello, > > This is what Brendan requested on the perf-users mailing list [1] to > support FlameGraphs [2] more efficiently. This patchset adds a few > more callchain options to adjust the output for it. >

Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

On Mon, Nov 2, 2015 at 2:12 PM, Namhyung Kim <namhy...@kernel.org> wrote: > Hi Arnaldo, > > On Mon, Nov 02, 2015 at 06:30:21PM -0300, Arnaldo Carvalho de Melo wrote: >> Em Mon, Nov 02, 2015 at 12:37:28PM -0800, Brendan Gregg escreveu: >> > G'Day Namhyung, >> &

Re: [RFC/PATCH 3/3] perf tools: Defaults to 'caller' callchain order only if --children is enabled

On Thu, Oct 22, 2015 at 7:03 AM, Arnaldo Carvalho de Melo <arnaldo.m...@gmail.com> wrote: > Em Thu, Oct 22, 2015 at 02:49:11AM -0700, Brendan Gregg escreveu: >> On Thu, Oct 22, 2015 at 12:38 AM, Namhyung Kim <namhy...@kernel.org> wrote: >> > Hi Ingo, >> > >

Re: [RFC/PATCH 3/3] perf tools: Defaults to 'caller' callchain order only if --children is enabled

On Thu, Oct 22, 2015 at 12:38 AM, Namhyung Kim wrote: > Hi Ingo, > > On Thu, Oct 22, 2015 at 4:32 PM, Ingo Molnar wrote: >> >> * Namhyung Kim wrote: >> >>> The caller callchain order is useful with --children option since it can >>> show 'overview' style output, but other commands which don't

Re: [RFC/PATCH 3/3] perf tools: Defaults to 'caller' callchain order only if --children is enabled

On Thu, Oct 22, 2015 at 12:38 AM, Namhyung Kim wrote: > Hi Ingo, > > On Thu, Oct 22, 2015 at 4:32 PM, Ingo Molnar wrote: >> >> * Namhyung Kim wrote: >> >>> The caller callchain order is useful with --children option since it can >>>

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Wed, Oct 21, 2015 at 12:23 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 21, 2015 at 11:28:54AM -0700, Brendan Gregg escreveu: >> On Tue, Oct 20, 2015 at 7:21 PM, Chandler Carruth >> wrote: >> > Since Arnaldo asked, I thought I should actually try to re

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Wed, Oct 21, 2015 at 1:06 AM, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > >> Indeed, finding a default that is deemed adequate for most people is, ho-hum, >> difficult 8-) >> >> Ingo, what do you think? > > So I think the new default is a lot more intuitive, because it starts

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Tue, Oct 20, 2015 at 7:21 PM, Chandler Carruth wrote: > Since Arnaldo asked, I thought I should actually try to respond specifically > to the question of why I favor the 'caller' view as the default. > > On Tue, Oct 20, 2015 at 3:06 AM Arnaldo Carvalho de Melo > wrote: >> >> > IMHO changing

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Tue, Oct 20, 2015 at 7:21 PM, Chandler Carruth wrote: > Since Arnaldo asked, I thought I should actually try to respond specifically > to the question of why I favor the 'caller' view as the default. > > On Tue, Oct 20, 2015 at 3:06 AM Arnaldo Carvalho de Melo >

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Wed, Oct 21, 2015 at 1:06 AM, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > >> Indeed, finding a default that is deemed adequate for most people is, ho-hum, >> difficult 8-) >> >> Ingo, what do you think? > > So I think the new default is

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Wed, Oct 21, 2015 at 12:23 PM, Arnaldo Carvalho de Melo <arnaldo.m...@gmail.com> wrote: > Em Wed, Oct 21, 2015 at 11:28:54AM -0700, Brendan Gregg escreveu: >> On Tue, Oct 20, 2015 at 7:21 PM, Chandler Carruth <chandl...@gmail.com> >> wrote: >> > Since Arnald

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Fri, Oct 9, 2015 at 3:25 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 09, 2015 at 03:10:29PM -0700, Brendan Gregg escreveu: >> On Fri, Oct 9, 2015 at 2:56 PM, Arnaldo Carvalho de Melo >> wrote: >> > >> > Em Fri, Oct 09, 2015 at 01:34:33PM -0700, Brendan G

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Mon, Oct 12, 2015 at 9:26 PM, Namhyung Kim wrote: > On Mon, Oct 05, 2015 at 06:03:35PM -0300, Arnaldo Carvalho de Melo wrote: >> From: Arnaldo Carvalho de Melo >> >> Which is the most common default found in other similar tools. > > I think it's more useful to change the default only when

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Mon, Oct 12, 2015 at 9:26 PM, Namhyung Kim wrote: > On Mon, Oct 05, 2015 at 06:03:35PM -0300, Arnaldo Carvalho de Melo wrote: >> From: Arnaldo Carvalho de Melo >> >> Which is the most common default found in other similar tools. > > I think it's more

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Fri, Oct 9, 2015 at 3:25 PM, Arnaldo Carvalho de Melo <arnaldo.m...@gmail.com> wrote: > Em Fri, Oct 09, 2015 at 03:10:29PM -0700, Brendan Gregg escreveu: >> On Fri, Oct 9, 2015 at 2:56 PM, Arnaldo Carvalho de Melo >> <arnaldo.m...@gmail.com> wrote: >> > >

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Sat, Oct 10, 2015 at 12:09 AM, Ingo Molnar wrote: > > * Brendan Gregg wrote: > >> On Fri, Oct 9, 2015 at 2:56 PM, Arnaldo Carvalho de Melo >> wrote: >> > >> > Em Fri, Oct 09, 2015 at 01:34:33PM -0700, Brendan Gregg escreveu: >> > > On Mo

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Sat, Oct 10, 2015 at 12:09 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Brendan Gregg <brendan.d.gr...@gmail.com> wrote: > >> On Fri, Oct 9, 2015 at 2:56 PM, Arnaldo Carvalho de Melo >> <arnaldo.m...@gmail.com> wrote: >> > >> > Em Fri,

Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

On Fri, Oct 9, 2015 at 2:56 PM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Oct 09, 2015 at 01:34:33PM -0700, Brendan Gregg escreveu: > > On Mon, Oct 5, 2015 at 2:03 PM, Arnaldo Carvalho de Melo > > wrote: > > > > > > From: Arnaldo Carvalho de Melo > >

  1   2   >