linux-kernel - Re: [PATCH v1] samples/bpf: Add a trace tool with perf PMU counters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <365689f8-12c1-44b3-a351-97e6f54c1928@iogearbox.net>
Date: Mon, 20 Jan 2025 20:54:30 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>,
 Leo Yan <leo.yan@....com>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
 <eddyz87@...il.com>, Song Liu <song@...nel.org>,
 Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
 James Clark <james.clark@...aro.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
 LKML <linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
 Quentin Monnet <qmo@...nel.org>
Subject: Re: [PATCH v1] samples/bpf: Add a trace tool with perf PMU counters

On 1/20/25 8:38 PM, Alexei Starovoitov wrote:
> On Mon, Jan 20, 2025 at 10:50 AM Leo Yan <leo.yan@....com> wrote:
>> On Mon, Jan 20, 2025 at 05:18:23PM +0100, Daniel Borkmann wrote:
>>> On 1/19/25 4:33 PM, Leo Yan wrote:
>>>> Developers might need to profile a program with fine-grained
>>>> granularity.  E.g., a user case is to account the CPU cycles for a small
>>>> program or for a specific function within the program.
>>>>
>>>> This commit introduces a small tool with using eBPF program to read the
>>>> perf PMU counters for performance metrics.  As the first step, the four
>>>> counters are supported with the '-e' option: cycles, instructions,
>>>> branches, branch-misses.
>>>>
>>>> The '-r' option is provided for support raw event number.  This option
>>>> is mutually exclusive to the '-e' option, users either pass a raw event
>>>> number or a counter name.
>>>>
>>>> The tool enables the counters for the entire trace session in free-run
>>>> mode.  It reads the beginning values for counters when the profiled
>>>> program is scheduled in, and calculate the interval when the task is
>>>> scheduled out.  The advantage of this approach is to dismiss the
>>>> statistics noise (e.g. caused by the tool itself) as possible.
>>
>> [...]
>>
>>> Thanks for this work! Few suggestions.. the contents of samples/bpf/ are in process of being
>>> migrated into BPF selftests given they have been bit-rotting for quite some time, so we'd like
>>> to migrate missing coverage into BPF CI (see test_progs in tools/testing/selftests/bpf/). That
>>> could be one option, or an alternative is to extend bpftool for profiling BPF programs (see
>>> 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")).
>>
>> Thanks for suggestions!
>>
>> The naming or info in the commit log might cause confuse.  The purpose
>> of this patch is to measure PMU counters for normal programs (not BPF
>> program specific).  To achieve profiling accuracy, it opens perf event
>> in thread mode, and support function based trace and can be userspace
>> mode only.
>>
>> My understanding for bpftool is for eBPF program specific.  I looked
>> into a bit the commit 47c09d6a9f67, it is nature for integrating the
>> tracing feature for eBPF program specific.  My patch is for tracing
>> normal userspace programs, I am not sure if this is really wanted by
>> bpftool.  I would like to hear opinions from bpftool maintainer before
>> proceeding.

Yes, that suggestion was if it would have been applicable also
for the existing bpftool (BPF program) profiling functionality.

>> My program mainly uses eBPF attaching to uprobe.  selftest/bpf has
>> contained the related functionality testing, actually I refered the
>> test for writing my code :).  So maybe it is not quite useful for
>> merging the code as a test?
>>
>> If both options are not ideal, I would spend time to land the
>> feature in perf tool - the perf tool has supported eBPF backend for
>> reading PMU counters, but it is absent function based profiling.
> 
> We don't add tools to kernel repo. bpftool is an exception
> because it's used during the selftest build.
> 'perf' is another exception for historical reasons.
> 
> This particular feature fits 'perf' the best.

Agree, looks like perf is the best target for integration then.