Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1452527 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] perf/core: Add a tracepoint for perf sampling Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-29 21:30 +0200
    Re: [PATCH] perf/core: Add a tracepoint for perf sampling Brendan Gregg <bgregg@netflix.com> - 2016-07-29 22:00 +0200

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

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, BPF can fetch
> stack traces and frequency count them in kernel context, for an efficient
> profiler.

Could you provide a complete experience? I.e. together with this patch a
bpf script that could then run, with the full set of steps needed to
show it in use.

Also, what would be the value when BPF is not used?

- Arnaldo
 
> Signed-off-by: Brendan Gregg <bgregg@netflix.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> ---
>  include/trace/events/perf.h | 29 +++++++++++++++++++++++++++++
>  kernel/events/core.c        |  5 +++++
>  2 files changed, 34 insertions(+)
>  create mode 100644 include/trace/events/perf.h
> 
> diff --git a/include/trace/events/perf.h b/include/trace/events/perf.h
> new file mode 100644
> index 0000000..461770d
> --- /dev/null
> +++ b/include/trace/events/perf.h
> @@ -0,0 +1,29 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM perf
> +
> +#if !defined(_TRACE_PERF_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_PERF_H
> +
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(perf_hrtimer,
> +	TP_PROTO(struct pt_regs *regs, struct perf_event *event),
> +
> +	TP_ARGS(regs, event),
> +
> +	TP_STRUCT__entry(
> +		__field(struct pt_regs *, regs)
> +		__field(struct perf_event *, event)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->regs = regs;
> +		__entry->event = event;
> +	),
> +
> +	TP_printk("regs=%p evt=%p", __entry->regs, __entry->event)
> +);
> +#endif /* _TRACE_PERF_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 79dae18..0d843a7 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -51,6 +51,9 @@
>  
>  #include <asm/irq_regs.h>
>  
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/perf.h>
> +
>  typedef int (*remote_function_f)(void *);
>  
>  struct remote_function_call {
> @@ -8036,6 +8039,8 @@ static enum hrtimer_restart perf_swevent_hrtimer(struct hrtimer *hrtimer)
>  	perf_sample_data_init(&data, 0, event->hw.last_period);
>  	regs = get_irq_regs();
>  
> +	trace_perf_hrtimer(regs, event);
> +
>  	if (regs && !perf_exclude_event(event, regs)) {
>  		if (!(event->attr.exclude_idle && is_idle_task(current)))
>  			if (__perf_event_overflow(event, 1, &data, regs))
> -- 
> 2.7.4

[toc] | [next] | [standalone]

#1452539

On Fri, Jul 29, 2016 at 12:21 PM, Arnaldo Carvalho de Melo
<acme@kernel.org> 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, BPF can fetch
>> stack traces and frequency count them in kernel context, for an efficient
>> profiler.
>
> Could you provide a complete experience? I.e. together with this patch a
> bpf script that could then run, with the full set of steps needed to
> show it in use.

There's currently profile.py, in bcc, which will either use this
tracepoint or use a kprobe if it doesn't exist (although the kprobe is
unreliable). profile samples stack traces and shows stack traces with
their occurrence counts. Eg:

# ./profile
Sampling at 49 Hertz of all threads by user + kernel stack... Hit Ctrl-C to end.
^C
    ffffffff81189249 filemap_map_pages
    ffffffff811bd3f5 handle_mm_fault
    ffffffff81065990 __do_page_fault
    ffffffff81065caf do_page_fault
    ffffffff817ce228 page_fault
    00007fed989afcc0 [unknown]
    -                cp (9036)
        1
[...]

    ffffffff8105eb66 native_safe_halt
    ffffffff8103659e default_idle
    ffffffff81036d1f arch_cpu_idle
    ffffffff810bba5a default_idle_call
    ffffffff810bbd07 cpu_startup_entry
    ffffffff817bf4a7 rest_init
    ffffffff81d65f58 start_kernel
    ffffffff81d652db x86_64_start_reservations
    ffffffff81d65418 x86_64_start_kernel
    -                swapper/0 (0)
        72

    ffffffff8105eb66 native_safe_halt
    ffffffff8103659e default_idle
    ffffffff81036d1f arch_cpu_idle
    ffffffff810bba5a default_idle_call
    ffffffff810bbd07 cpu_startup_entry
    ffffffff8104df55 start_secondary
    -                swapper/1 (0)
        75

Tool and examples are on github [1][2]. Is this sufficient for this
patch? If not, I could rewrite something for samples/bpf (eg, an IP
sampler, or a task priority sampler), which I may do anyway as a
follow-on if they turned out to be nice examples.

>
> Also, what would be the value when BPF is not used?
>

No big reason comes to mind. I could imagine it might be useful when
debugging perf's sampling behavior, and there might be uses with
ftrace as well. But the big reason is extending perf's existing
sampling capabilities for in-kernel frequency counts of stack traces
(which could include custom BPF-based stack walkers), IP, task
priority, etc. Thanks,

Brendan

[1] https://github.com/iovisor/bcc/blob/master/tools/profile.py
[2] https://github.com/iovisor/bcc/blob/master/tools/profile_example.txt

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web