From: Menglong Dong <menglong.dong@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Menglong Dong <menglong8.dong@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Menglong Dong <dongml2@chinatelecom.cn>
Subject: Re: [PATCH bpf-next v3] bpf: make the attach target more accurate
Date: Tue, 15 Jul 2025 07:32:05 +0800 [thread overview]
Message-ID: <324a7b0b-ccff-4d8b-b0a2-f810e90f74f8@linux.dev> (raw)
In-Reply-To: <CAADnVQLHORFKC3PzJ540xxa_bETBypXu2-z7Z+8c+as97vByXA@mail.gmail.com>
On 2025/7/15 06:29, Alexei Starovoitov wrote:
> On Mon, Jul 14, 2025 at 2:50 PM Menglong Dong <menglong.dong@linux.dev> wrote:
>>
>> On 2025/7/15 03:52, Alexei Starovoitov wrote:
>>> On Thu, Jul 10, 2025 at 12:10 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
>>>> } else {
>>>> - addr = kallsyms_lookup_name(tname);
>>>> + ret = bpf_lookup_attach_addr(NULL, tname, &addr);
>>>> }
>>> Not sure why your benchmarking doesn't show the difference,
>>> but above is a big regression.
>>> kallsyms_lookup_name() is a binary search whereas your
>>> bpf_lookup_attach_addr() is linear.
>>> You should see a massive degradation in multi-kprobe attach speeds.
>>
>> Hi, Alexei. Like I said above, the benchmarking does have
>> a difference for the symbol in the modules, which makes
>> the attachment time increased from 0.135543s to 0.176904s
>> for 8631 symbols. As the symbols in the modules
>> is not plentiful, which makes the overhead slight(or not?).
>>
>> But for the symbol in vmlinux, bpf_lookup_attach_addr() will
>> call kallsyms_on_each_match_symbol(), which is also
>> a binary search, so the benchmarking has no difference,
>> which makes sense.
> I see.
> Just curious, what was the function count in modules on your system ?
> cat /proc/kallsyms|grep '\['|grep -v bpf|wc -l
Hi, it's about 34k:
cat/proc/kallsyms|grep'\['|grep-vbpf|wc-l
34740
>
> Only now I read the diff carefully enough to realize that
> you're looking for duplicates across vmlinux and that one module.
>
> Why ?
> BTF based attachment identifies a specific module.
> Even if there are dups between that module and vmlinux the attachment
> is not ambiguous.
When the module is not specified, kallsyms_lookup_name() will be called in
bpf_check_attach_target() to get the address. And
kallsyms_lookup_name() will lookup the symbols in the vmlinux
first. If not found, it will lookup it in the modules. And in this
commit, I follow this logic.
So I lookup duplicates accross vmlinux and modules only when
the modules is not specified, and that's reasonable. However,
we always find the address in the vmlinux if module is not specified,
as the btf type belong to the vmlinux. So we will never lookup the
symbols in the modules if "mod" is not specified, which means
bpf_lookup_attach_addr() won't lookup duplicates accross vmlinux
and modules.
So just forget it :/
Thanks!
Menglong Dong
>
>> I thought we don't need this patch after the pahole fixes this
>> problem. Should I send a V4?
> pahole should fix it, so this change is not needed.
> But pahole will be removing the dups within vmlinux and
> within each module independently. Not across them.
> I don't think "across" is needed, but you somehow believe that
> it's necessary ? (based on this diff)
prev parent reply other threads:[~2025-07-14 23:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 7:08 [PATCH bpf-next v3] bpf: make the attach target more accurate Menglong Dong
2025-07-10 23:24 ` Andrii Nakryiko
2025-07-11 1:27 ` Menglong Dong
2025-07-11 3:10 ` Yonghong Song
2025-07-11 3:46 ` Yonghong Song
2025-07-11 5:51 ` Menglong Dong
2025-07-11 6:37 ` Menglong Dong
2025-07-11 11:23 ` Jiri Olsa
2025-07-11 12:01 ` Menglong Dong
2025-07-14 19:52 ` Alexei Starovoitov
2025-07-14 21:50 ` Menglong Dong
2025-07-14 22:29 ` Alexei Starovoitov
2025-07-14 23:32 ` Menglong Dong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=324a7b0b-ccff-4d8b-b0a2-f810e90f74f8@linux.dev \
--to=menglong.dong@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dongml2@chinatelecom.cn \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=menglong8.dong@gmail.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).