From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Andrii Nakryiko <andrii@kernel.org>,
linux-fsdevel@vger.kernel.org, brauner@kernel.org,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
linux-mm@kvack.org, Arnaldo Carvalho de Melo <acme@kernel.org>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc/<pid>/maps APIs
Date: Sat, 4 May 2024 14:57:17 -0700 [thread overview]
Message-ID: <CAEf4BzaUgGJVqw_yWOXASHManHQWGQV905Bd-wiaHj-mRob9gw@mail.gmail.com> (raw)
In-Reply-To: <2024050404-rectify-romp-4fdb@gregkh>
On Sat, May 4, 2024 at 8:29 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote:
> > Implement a simple tool/benchmark for comparing address "resolution"
> > logic based on textual /proc/<pid>/maps interface and new binary
> > ioctl-based PROCFS_PROCMAP_QUERY command.
>
> Of course an artificial benchmark of "read a whole file" vs. "a tiny
> ioctl" is going to be different, but step back and show how this is
> going to be used in the real world overall. Pounding on this file is
> not a normal operation, right?
>
It's not artificial at all. It's *exactly* what, say, blazesym library
is doing (see [0], it's Rust and part of the overall library API, I
think C code in this patch is way easier to follow for someone not
familiar with implementation of blazesym, but both implementations are
doing exactly the same sequence of steps). You can do it even less
efficiently by parsing the whole file, building an in-memory lookup
table, then looking up addresses one by one. But that's even slower
and more memory-hungry. So I didn't even bother implementing that, it
would put /proc/<pid>/maps at even more disadvantage.
Other applications that deal with stack traces (including perf) would
be doing one of those two approaches, depending on circumstances and
level of sophistication of code (and sensitivity to performance).
[0] https://github.com/libbpf/blazesym/blob/ee9b48a80c0b4499118a1e8e5d901cddb2b33ab1/src/normalize/user.rs#L193
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2024-05-04 21:57 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-04 0:30 [PATCH 0/5] ioctl()-based API to query VMAs from /proc/<pid>/maps Andrii Nakryiko
2024-05-04 0:30 ` [PATCH 1/5] fs/procfs: extract logic for getting VMA name constituents Andrii Nakryiko
2024-05-04 0:30 ` [PATCH 2/5] fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps Andrii Nakryiko
2024-05-04 15:28 ` Greg KH
2024-05-04 21:50 ` Andrii Nakryiko
2024-05-06 13:58 ` Arnaldo Carvalho de Melo
2024-05-06 18:05 ` Namhyung Kim
2024-05-06 18:51 ` Andrii Nakryiko
2024-05-06 18:53 ` Arnaldo Carvalho de Melo
2024-05-06 19:16 ` Arnaldo Carvalho de Melo
2024-05-07 21:55 ` Namhyung Kim
2024-05-06 18:41 ` Andrii Nakryiko
2024-05-06 20:35 ` Arnaldo Carvalho de Melo
2024-05-07 16:36 ` Andrii Nakryiko
2024-05-04 23:36 ` kernel test robot
2024-05-07 18:10 ` Liam R. Howlett
2024-05-07 18:52 ` Andrii Nakryiko
2024-05-04 0:30 ` [PATCH 3/5] tools: sync uapi/linux/fs.h header into tools subdir Andrii Nakryiko
2024-05-04 0:30 ` [PATCH 4/5] selftests/bpf: make use of PROCFS_PROCMAP_QUERY ioctl, if available Andrii Nakryiko
2024-05-04 0:30 ` [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc/<pid>/maps APIs Andrii Nakryiko
2024-05-04 15:29 ` Greg KH
2024-05-04 21:57 ` Andrii Nakryiko [this message]
2024-05-05 5:09 ` Ian Rogers
2024-05-06 18:32 ` Andrii Nakryiko
2024-05-06 18:43 ` Ian Rogers
2024-05-07 5:06 ` Andrii Nakryiko
2024-05-07 17:29 ` Andrii Nakryiko
2024-05-07 22:27 ` Namhyung Kim
2024-05-07 22:56 ` Andrii Nakryiko
2024-05-08 0:36 ` Arnaldo Carvalho de Melo
2024-05-04 15:32 ` Greg KH
2024-05-04 22:13 ` Andrii Nakryiko
2024-05-07 15:48 ` Liam R. Howlett
2024-05-07 16:10 ` Matthew Wilcox
2024-05-07 16:18 ` Liam R. Howlett
2024-05-07 16:27 ` Andrii Nakryiko
2024-05-07 18:06 ` Liam R. Howlett
2024-05-07 19:00 ` Andrii Nakryiko
2024-05-08 1:20 ` Liam R. Howlett
2024-05-04 11:24 ` [PATCH 0/5] ioctl()-based API to query VMAs from /proc/<pid>/maps Christian Brauner
2024-05-04 15:33 ` Greg KH
2024-05-04 21:50 ` Andrii Nakryiko
2024-05-04 21:50 ` Andrii Nakryiko
2024-05-05 5:26 ` Ian Rogers
2024-05-06 18:58 ` Andrii Nakryiko
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=CAEf4BzaUgGJVqw_yWOXASHManHQWGQV905Bd-wiaHj-mRob9gw@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).