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
Subject: Re: [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc/<pid>/maps APIs
Date: Sat, 4 May 2024 15:13:25 -0700 [thread overview]
Message-ID: <CAEf4BzbiTQk6pLPQj=p9d18YW4fgn9k2V=zk6nUYAOK975J=xg@mail.gmail.com> (raw)
In-Reply-To: <2024050425-setting-enhance-3bcd@gregkh>
On Sat, May 4, 2024 at 8:32 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote:
> > I also did an strace run of both cases. In text-based one the tool did
> > 68 read() syscalls, fetching up to 4KB of data in one go.
>
> Why not fetch more at once?
>
I didn't expect to be interrogated so much on the performance of the
text parsing front, sorry. :) You can probably tune this, but where is
the reasonable limit? 64KB? 256KB? 1MB? See below for some more
production numbers.
> And I have a fun 'readfile()' syscall implementation around here that
> needs justification to get merged (I try so every other year or so) that
> can do the open/read/close loop in one call, with the buffer size set by
> userspace if you really are saying this is a "hot path" that needs that
> kind of speedup. But in the end, io_uring usually is the proper api for
> that instead, why not use that here instead of slow open/read/close if
> you care about speed?
>
I'm not sure what I need to say here. I'm sure it will be useful, but
as I already explained, it's not about the text file or not, it's
about having to read too much information that's completely
irrelevant. Again, see below for another data point.
> > In comparison,
> > ioctl-based implementation had to do only 6 ioctl() calls to fetch all
> > relevant VMAs.
> >
> > It is projected that savings from processing big production applications
> > would only widen the gap in favor of binary-based querying ioctl API, as
> > bigger applications will tend to have even more non-executable VMA
> > mappings relative to executable ones.
>
> Define "bigger applications" please. Is this some "large database
> company workload" type of thing, or something else?
I don't have a definition. But I had in mind, as one example, an
ads-serving service we use internally (it's a pretty large application
by pretty much any metric you can come up with). I just randomly
picked one of the production hosts, found one instance of that
service, and looked at its /proc/<pid>/maps file. Hopefully it will
satisfy your need for specifics.
# cat /proc/1126243/maps | wc -c
1570178
# cat /proc/1126243/maps | wc -l
28875
# cat /proc/1126243/maps | grep ' ..x. ' | wc -l
7347
You can see that maps file itself is about 1.5MB of text (which means
single-shot reading of its entire contents is a bit unrealistic,
though, sure, why not). The process contains 28875 VMAs, out of which
only 7347 are executable.
This means if we were to profile this process (and normally we profile
entire system, so it's almost never single /proc/<pid>/maps file that
needs to be open and processed), we'd need *at most* (absolute worst
case!) 7347/28875 = 25.5% of entries. In reality, most code will be
concentrated in a much smaller number of executable VMAs, of course.
But no, I don't have specific numbers at hand, sorry.
It matters less whether it's text or binary (though binary undoubtedly
will be faster, it's strange to even argue about this), it's the
ability to fetch only relevant VMAs that is the point here.
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2024-05-04 22:13 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
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 [this message]
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='CAEf4BzbiTQk6pLPQj=p9d18YW4fgn9k2V=zk6nUYAOK975J=xg@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--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=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).