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 pri
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
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 s
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
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 s
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
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.
>>
>> $
]
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
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 sa
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 p
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
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
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 inste
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
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 discussed.
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
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 stil
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
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
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
&
), 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
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
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
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 for
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
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
&
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
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
>
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
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
> strlist__for_each_entry
kcollapse-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
&
> 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
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 impleme
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 in
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
>>
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:
>> >
>> > 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 chan
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, acc
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 field
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
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 cal
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
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 M
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'
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 us
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 respond
&
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 wi
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 th
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
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 --ch
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
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
> >
On Sun, Oct 4, 2015 at 1:05 PM, Stephane Eranian wrote:
>
> Brendan,
>
> On Thu, Oct 1, 2015 at 3:45 PM, Brendan Gregg
> wrote:
> > G'Day,
> >
> > On Wed, Sep 30, 2015 at 11:45 PM, Stephane Eranian
> > wrote:
> >>
> >> T
On Mon, Oct 5, 2015 at 2:03 PM, Arnaldo Carvalho de Melo
wrote:
>
> From: Arnaldo Carvalho de Melo
>
> Which is the most common default found in other similar tools.
Interactive tools, sure, like the perf report TUI.
But this also changes the ordering of the non-interactive tools which
dump st
G'Day,
On Wed, Sep 30, 2015 at 11:45 PM, Stephane Eranian wrote:
>
> This patch series extends perf record/report/annotate to enable
> profiling of jitted (just-in-time compiled) code. The current
> perf tool provides very limited support for profiling jitted
> code for some runtime environments.
G'Day Tom,
On Thu, Jul 16, 2015 at 10:22 AM, Tom Zanussi
wrote:
>
> This is v9 of the 'hist triggers' patchset.
>
[...]
I've browsed the functionality (sorry, catching up), and it looks like
this will solve a number of common problems. But it seems
tantalizingly close to solving a few more. Thes
G'Day Masami-san, Namhyung,
I'm really looking forward to this feature -- very useful, thanks!...
On Sat, Jul 18, 2015 at 9:24 PM, Namhyung Kim wrote:
> Hi Masami,
>
> On Fri, Jul 17, 2015 at 12:21:42PM +0900, Masami Hiramatsu wrote:
>> Now I'm thinking that we should avoid using %event syntax f
On Thu, Apr 30, 2015 at 3:52 AM, Wang Nan wrote:
[...]
> An example is pasted at the bottom of this cover letter. In that
> example, mybpfprog is configured by string in config section, and will
> be probed at __alloc_pages_nodemask. sample_bpf.o is generated using:
>
> $ $CLANG -I/usr/src/kernel
On Tue, Mar 31, 2015 at 12:33 AM, Brendan Gregg
wrote:
> G'Day Stephane,
>
> On Mon, Mar 30, 2015 at 3:19 PM, Stephane Eranian wrote:
> [...]
>> The current support only works when the runtime is monitored from
>> start to finish: perf record java --agentpath:libpfm
G'Day Stephane,
On Mon, Mar 30, 2015 at 3:19 PM, Stephane Eranian wrote:
[...]
> The current support only works when the runtime is monitored from
> start to finish: perf record java --agentpath:libpfmjvmti.so my_class.
>
> Once the run is completed, the jitdump file needs to be injected into
> t
On Tue, Sep 9, 2014 at 5:03 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> It's currently difficult to filter out perf itself using a filter.
> This can give cascading effects during IO tracing when the IO
> perf does itself causes more trace output.
>
> The best way to filter is to use the pid. Bu
On Thu, Aug 14, 2014 at 6:51 PM, Masami Hiramatsu
wrote:
> Here is v2 patch, which I've added "or install an appropriate debuginfo
> pacakge." :)
[...]
Looks good, thanks.
Brendan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov wrote:
[...]
> maps can have different types: hash, bloom filter, radix-tree, etc.
>
> The map is defined by:
> . type
> . max number of elements
> . key size in bytes
> . value size in bytes
Can values be strings or byte arrays? How wo
On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov wrote:
> this example has two probes in C that use two different maps.
>
> 1st probe is the similar to dropmon.c. It attaches to kfree_skb tracepoint and
> count number of packet drops at different locations
>
> 2nd probe attaches to kprobe/sys_
On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov wrote:
[...]
> +/* For tracing filters save first six arguments of tracepoint events.
> + * On 64-bit architectures argN fields will match one to one to arguments
> passed
> + * to tracepoint events.
> + * On 32-bit architectures u64 arguments
On Thu, Aug 14, 2014 at 11:29 AM, Masami Hiramatsu
wrote:
[...]
> The "rebuild with ..." part changes to "rebuild with CONFIG_DEBUG_INFO"
> if the target is the kernel or a kernel module.
Thanks, definitely an improvement! Should the kernel message also
mention kernel debuginfo packages? Depends
On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov wrote:
[...]
> +static int load_and_attach(const char *event, struct bpf_insn *prog, int
> size)
> +{
> + int fd, event_fd, err;
> + char fmt[32];
> + char path[256] = DEBUGFS;
> +
> + fd = bpf_prog_load(BPF_PROG_TYPE_TR
On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov wrote:
[...]
> Tracing use case got some improvements as well. Now eBPF programs can be
> attached to tracepoint, syscall, kprobe and C examples are more usable:
> ex1_kern.c - demonstrate how programs can walk in-kernel data structures
> ex2_ke
68 matches
Mail list logo
