linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	linux-fsdevel@vger.kernel.org, brauner@kernel.org,
	 viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org,  gregkh@linuxfoundation.org,
	linux-mm@kvack.org, liam.howlett@oracle.com,  surenb@google.com,
	rppt@kernel.org, adobriyan@gmail.com
Subject: Re: [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps
Date: Thu, 27 Jun 2024 13:50:22 -0700	[thread overview]
Message-ID: <CAEf4BzaNOrMWB=nimR-UD8-MrC37kHQi6fh1hBv+aPWvoiSm5A@mail.gmail.com> (raw)
In-Reply-To: <20240627125938.da3541c6babfe046f955df7a@linux-foundation.org>

On Thu, Jun 27, 2024 at 12:59 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Thu, 27 Jun 2024 10:08:52 -0700 Andrii Nakryiko <andrii@kernel.org> wrote:
>
> > Implement binary ioctl()-based interface to /proc/<pid>/maps file to allow
> > applications to query VMA information more efficiently than reading *all* VMAs
> > nonselectively through text-based interface of /proc/<pid>/maps file.
>
> I appreciate the usefulness for monitoring large fleets, so I'll add
> this version to mm-unstable.  As we're almost at -rc6 I'll await
> further review before deciding on the next steps.
>
> Is it possible/sensible to make this feature Kconfigurable so that people who
> don't need it can omit it?

It's just a matter of #ifdef/#endif, so not hard, technically
speaking. But I'm wondering what's the concern? This is mostly newly
added code (except factoring out get_vma_name logic, which won't be
#ifdef'ed anyways), so if no one is using this new API, then it should
cause no issue.

Generally speaking, I'd say if we don't *have to* add the Kconfig
option, I'd prefer that. But if you feel strongly, it's not hard for
me to do, of course.

Or are you concerned with the vmlinux code size increase? It doesn't
seem to be large enough to warrant a Kconfig, IMO (from
bloat-o-meter):

do_procmap_query                               -    1308   +1308
get_vma_name                                   -     283    +283
procfs_procmap_ioctl                           -      47     +47
show_map_vma                                 444     274    -170

But again, do let me know if you insist.


  reply	other threads:[~2024-06-27 20:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 17:08 Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 1/6] fs/procfs: extract logic for getting VMA name constituents Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 2/6] fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API Andrii Nakryiko
2024-06-27 23:00   ` Andi Kleen
2024-06-28 16:36     ` Andrii Nakryiko
2024-06-28 22:33       ` Andi Kleen
2024-06-28 23:03         ` Andrii Nakryiko
2024-07-02 14:49           ` Andi Kleen
2024-07-02 23:08             ` Andrii Nakryiko
2024-07-08 23:43             ` Andrii Nakryiko
2024-07-09  1:27               ` Andi Kleen
2024-07-09  3:14                 ` Andrii Nakryiko
2024-07-29 15:47   ` Jann Horn
2024-07-29 16:52     ` Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 4/6] docs/procfs: call out ioctl()-based PROCMAP_QUERY command existence Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 5/6] tools: sync uapi/linux/fs.h header into tools subdir Andrii Nakryiko
2024-06-27 17:08 ` [PATCH v6 6/6] selftests/proc: add PROCMAP_QUERY ioctl tests Andrii Nakryiko
2024-06-27 19:59 ` [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps Andrew Morton
2024-06-27 20:50   ` Andrii Nakryiko [this message]
2024-06-27 21:11     ` Andrew Morton
2024-06-28 16:42       ` Andrii Nakryiko
2024-07-10 18:32 ` Andrew Morton
2024-07-10 18:41   ` Andrii Nakryiko
2024-07-11 18:07 ` Liam R. Howlett
2024-07-24 16:32   ` Alexey Dobriyan

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='CAEf4BzaNOrMWB=nimR-UD8-MrC37kHQi6fh1hBv+aPWvoiSm5A@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=adobriyan@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=liam.howlett@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --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