From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 855C0C10F1A for ; Tue, 7 May 2024 16:37:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C9766B0089; Tue, 7 May 2024 12:37:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07A566B009B; Tue, 7 May 2024 12:37:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5D5F6B009C; Tue, 7 May 2024 12:37:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C80186B0089 for ; Tue, 7 May 2024 12:37:08 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7BC89160E7A for ; Tue, 7 May 2024 16:37:08 +0000 (UTC) X-FDA: 82092154536.19.593B27B Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 9D12E40018 for ; Tue, 7 May 2024 16:37:06 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wu9iAv8h; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715099826; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=h4OwR2TgrDTiiCg6OQZ7l2+opI9M0Uh+nYNlleYZodA=; b=2uDekph/UO9tU+0+E73OptJlZ7eASHHI7gXxBaNoeHAtisY/8i3yGZHl0eqegE1CIy39jq 35+9LafJJXSOb0Uk0C8EcLSueArGXeEknYF5t62SsaHftD4sqEfdv2uzeQwMkVA2LfdVSI S3St7f4g9SzU9grrS1b7aCQr+2vlB4Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715099826; a=rsa-sha256; cv=none; b=KM2WCuxo7cb30ZL3OaN/0yMbDnHoSW3ZKaAZyY2pKX89kiNft6E7foKCgSPOQ9M5X3WaG8 huv28ewo8hZZQ6SUutFmcZigLAEa6YbhVog2ZjU4XgiyNjd37F9LKezNk79C3PEou6IL1+ VeIZv2GfEeJWeTIS2oMYAkYYvDACgWQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wu9iAv8h; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-628a551d10cso1519402a12.1 for ; Tue, 07 May 2024 09:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715099825; x=1715704625; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=h4OwR2TgrDTiiCg6OQZ7l2+opI9M0Uh+nYNlleYZodA=; b=Wu9iAv8hvm22fyyqboXBkQclBjLs5EuwSnEKc5qvI814lzYW9KnYnn0hgZUhG1tpAB PAsZ75O8CE0uqi+SEYbjMism7lG2nguWOY7Ig//qKNdo6TZwgM+H5RiiXdDvbBMcQz/q HaMKWzE5W6kyPqyCWPGdSglEXGLWqAXUuyzR2mH7FeJYXrHnjUSFbcyUvbGPIEhHf1V7 yKFRBFHJYnQ75ddf+GRb5p1XZ1xpF5qmmAvF4rItrp4HUpBKMCOuoJlXE/2jSW9eZh0j pwWhdZbKq9rAhirR05iCbIhfUoTaCS7ME0uPNo6MzQLM0Cse+XnMdD3Qf6mRZRpP4WS9 768g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715099825; x=1715704625; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=h4OwR2TgrDTiiCg6OQZ7l2+opI9M0Uh+nYNlleYZodA=; b=iAdh7MS2J7819MJk+7yWKHNDgPnMwU85fqlUg74/cCd1WX/qRE/HsLFkljUk4wRT5H 0gDklneI3Xmsw3vop8lLjIn8xEZpjZ2N82haF1fpmO/iV2tCa5ffLscVwDg/jmpQ+sO3 GbrO4rN0n6eQhpN3xLu3vMgDcvPZJI3dlWZBgHeNva0FuMWBnhRDBugT9eBV29ql+w+5 KTfQVA42+XVvJSJ/XZRMZUX0MbHtOlCr4WJK7u16o4giT9gDCtksVTFxt47qPyOgoUuK dmlvpZijZFbKIiKMgQ2NTfEGkB7rEVzxg+Ziad8bxp/MFS3DKQey/3BRkHxkNGnDOck/ YWNQ== X-Forwarded-Encrypted: i=1; AJvYcCVfc68F2P8uK4/JqPntj8WvsaMsEm9bQl3R52oYnxGPZW9sZzrEY1F9cC0pQjVsn9nm6495604pm+sXwqyuX5HfD5U= X-Gm-Message-State: AOJu0YyDNj7acRPhynYfwWiTZNu+tyg6sBHLm9IxnZvfV5noONaB9aeg hh7+V9IxFIpN9K7ReNvo/JjrVzgkDFJtfDKb4YWY/m/OwANO/GIK35XdcKKh/J76nHDk7d/8dc2 ZJRUT6Ym6WOD7Pes9WS2zeep+A9c= X-Google-Smtp-Source: AGHT+IHJgrwGB4ntGMYQujEHAZAA3qer5jlfBLoOJ9WIa4Ibk405hMwVEWVotrCPoLmMIPRvDSQO5cKYoauW1OsRePs= X-Received: by 2002:a17:90a:d14f:b0:2b2:bccc:5681 with SMTP id 98e67ed59e1d1-2b6169e3210mr75104a91.33.1715099825278; Tue, 07 May 2024 09:37:05 -0700 (PDT) MIME-Version: 1.0 References: <20240504003006.3303334-1-andrii@kernel.org> <20240504003006.3303334-3-andrii@kernel.org> <2024050439-janitor-scoff-be04@gregkh> In-Reply-To: From: Andrii Nakryiko Date: Tue, 7 May 2024 09:36:52 -0700 Message-ID: Subject: Re: [PATCH 2/5] fs/procfs: implement efficient VMA querying API for /proc//maps To: Arnaldo Carvalho de Melo Cc: Jiri Olsa , Ian Rogers , Greg KH , Andrii Nakryiko , 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, =?UTF-8?Q?Daniel_M=C3=BCller?= , "linux-perf-use." Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9D12E40018 X-Stat-Signature: jr4w5dz7k3mj3eb1beexgqwaoexs6mij X-Rspam-User: X-HE-Tag: 1715099826-218531 X-HE-Meta: U2FsdGVkX1+F8OcYfNdEFxr+LUQgfo1sxuZBdNd8Cdnv8vu7vL82OCRY3rXRmkwGuXww9FSnaFL1dYKzQ2CTWAdYX/NS7lWXHu6LbwiCulBcV/bXvC61oT6fd9e1oBWWW9aLtbPJRa5J1LPb0Moxjx8z2jQG3ItZ3OSdzd58IN33jqkk0SwGX/gx8de6yJfMJqvWWT7fdO1JdqrofUhetMMEWKtIqew1eb7DnEUe+apkFefrUn9VoE0gHuw8g3DC0TbY7LNVD8AMk2xMeBGdmt2B6cqgHSe0NZz0tBWNI7pK4Fu9TBhFvIvnksvFZ+U8erzHrrD2960EnudsNbA7aWHu3kKVOCjZVK71yS+kJX/9I1sRhx1odWIkUdg7UVsAc6/duG4cLHmUtrHE08drG+5NhenSGfr3I6YIHQsHgtjMv6u6+fyjvVojW/FSGajdNvl4ppghMa9uOHaNYWPjboCLFtKuK8WvciMRqCOJ8hsgvHjKgeu94KNM6QTU6MttWO9cFdtDLKMJ4Ucvgw1iDh/fQll2qmW8AOabk7idDNe5cEZUvjAreuWR6Dz+kd7b2yPR8RwGl3pw7ods8QKM2C2LAXRM+Q8dW7gfKmW5rozWRX6cK5W/LDdzw2/OLbbdRGy1ennzvJN0fvot3q3BVTxc3m2mWeAYFFqQ1ROuUUVve2L8NNt6kEAdmj9GIajSLCDFbZoPQI2ImZyBKUM+SY2kFX5OELasxPd5eFpBWv1VLL3BoLaqqyNGA4SENzVAXmv/zo/wJ8g55f0T3JBojQMwnIZi6jJD2EurQQIiTNzoiOnVc8pfm0YNeonxQms7jnmGWkUIo7UZ87CB88L1scTGBvj18KKNcqaVpuIns7itQuJlahsVSQhF5JyNaTsvXV8JmzVnIh9tAKA/FqIpjQ4KSD2ru6o+xL1TfaMlHaLQbbJogP5FrcPJirBxowbSpcrRglqepxKl8aapXTk 0iVFrQMD 1Fc/zQNQPsVL1ETSvx52Y8Q5Kb93Tvjp2swbOSIqAcLTZfG250W2UbJ1MyiINaIicsVIVZXRSePJ38miZeatX4g428nP1QG3+J4OBdUV18wY5hTkEGW+W9b4CaIVu0NyPsk5dJ/3sU6KAKiisJ3XQOR3mU35CBYvgFEt3p5E80hS+Yu0glB1/ebvsIRYOfB4wBFDn8+Yaje/sk8ATXYqp3Wl5FXZHeAc96+8m1QH5rCbEXjspvq1yqQwcHjWQXI98n1RTFJmtHmbs7tKI6PWGddimKVqL8dVG81/GdQRXe/23zH/SDY7ZPlCgmzF+bkiaESkAN4qYU7py5w7R1Dx6cR9uRWk3BOtdzICe7djwMwgdMnUZ+2B8XLMsFTNCnOHLk/atn0ajdttJ4V96asyCn0QpwkbSkGBs939gzagZWo5ZY9hwZy8ZLrQoNTY/EDWdN3ZbAEMxqNO1e+GUFJFZMis9t4QbP8/HkOp4DdXSVda39xepWOvUYtIVIKbcz+nVxyXC7u+OsZGAy3+8PVDV5NAChw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, May 6, 2024 at 1:35=E2=80=AFPM Arnaldo Carvalho de Melo wrote: > > On Mon, May 06, 2024 at 11:41:43AM -0700, Andrii Nakryiko wrote: > > On Mon, May 6, 2024 at 6:58=E2=80=AFAM Arnaldo Carvalho de Melo wrote: > > > > > > On Sat, May 04, 2024 at 02:50:31PM -0700, Andrii Nakryiko wrote: > > > > On Sat, May 4, 2024 at 8:28=E2=80=AFAM Greg KH wrote: > > > > > On Fri, May 03, 2024 at 05:30:03PM -0700, Andrii Nakryiko wrote: > > > > > > Note also, that fetching VMA name (e.g., backing file path, or = special > > > > > > hard-coded or user-provided names) is optional just like build = ID. If > > > > > > user sets vma_name_size to zero, kernel code won't attempt to r= etrieve > > > > > > it, saving resources. > > > > > > > > > Signed-off-by: Andrii Nakryiko > > > > > > > > Where is the userspace code that uses this new api you have creat= ed? > > > > > > > So I added a faithful comparison of existing /proc//maps vs ne= w > > > > ioctl() API to solve a common problem (as described above) in patch > > > > #5. The plan is to put it in mentioned blazesym library at the very > > > > least. > > > > > > > > I'm sure perf would benefit from this as well (cc'ed Arnaldo and > > > > linux-perf-user), as they need to do stack symbolization as well. > > > > > > At some point, when BPF iterators became a thing we thought about, II= RC > > > Jiri did some experimentation, but I lost track, of using BPF to > > > synthesize PERF_RECORD_MMAP2 records for pre-existing maps, the layou= t > > > as in uapi/linux/perf_event.h: > > > > > > /* > > > * The MMAP2 records are an augmented version of MMAP, they a= dd > > > * maj, min, ino numbers to be used to uniquely identify each= mapping > > > * > > > * struct { > > > * struct perf_event_header header; > > > * > > > * u32 pid, tid; > > > * u64 addr; > > > * u64 len; > > > * u64 pgoff; > > > * union { > > > * struct { > > > * u32 maj; > > > * u32 min; > > > * u64 ino; > > > * u64 ino_generation; > > > * }; > > > * struct { > > > * u8 build_id_size; > > > * u8 __reserved_1; > > > * u16 __reserved_2; > > > * u8 build_id[20]; > > > * }; > > > * }; > > > * u32 prot, flags; > > > * char filename[]; > > > * struct sample_id sample_id; > > > * }; > > > */ > > > PERF_RECORD_MMAP2 =3D 10, > > > > > > * PERF_RECORD_MISC_MMAP_BUILD_ID - PERF_RECORD_MMAP2 event > > > > > > As perf.data files can be used for many purposes we want them all, so= we > > > > ok, so because you want them all and you don't know which VMAs will be > > useful or not, it's a different problem. BPF iterators will be faster > > purely due to avoiding binary -> text -> binary conversion path, but > > other than that you'll still retrieve all VMAs. > > But not using tons of syscalls to parse text data from /proc. In terms of syscall *count* you win with 4KB text reads, there are fewer syscalls because of this 4KB-based batching. But the cost of syscall + amount of user-space processing is a different matter. My benchmark in perf (see patch #5 discussion) suggests that even with more ioctl() syscalls, perf would win here. But I also realized that what you really need (I think, correct me if I'm wrong) is only file-backed VMAs, because all the other ones are not that useful for symbolization. So I'm adding a minimal change to my code to allow the user to specify another query flag to only return file-backed VMAs. I'm going to try it with perf code and see how that helps. I'll post results in patch #5 thread, once I have them. > > > You can still do the same full VMA iteration with this new API, of > > course, but advantages are probably smaller as you'll be retrieving a > > full set of VMAs regardless (though it would be interesting to compare > > anyways). > > sure, I can't see how it would be faster, but yeah, interesting to see > what is the difference. see patch #5 thread, seems like it's still a bit faster > > > > setup a meta data perf file descriptor to go on receiving the new mma= ps > > > while we read /proc//maps, to reduce the chance of missing maps,= do > > > it in parallel, etc: > > > > > > =E2=AC=A2[acme@toolbox perf-tools-next]$ perf record -h 'event synthe= sis' > > > > > > Usage: perf record [] [] > > > or: perf record [] -- [] > > > > > > --num-thread-synthesize > > > number of threads to run for event synthesi= s > > > --synth > > > Fine-tune event synthesis: default=3Dall > > > > > > =E2=AC=A2[acme@toolbox perf-tools-next]$ > > > > > > For this specific initial synthesis of everything the plan, as mentio= ned > > > about Jiri's experiments, was to use a BPF iterator to just feed the > > > perf ring buffer with those events, that way userspace would just > > > receive the usual records it gets when a new mmap is put in place, th= e > > > BPF iterator would just feed the preexisting mmaps, as instructed via > > > the perf_event_attr for the perf_event_open syscall. > > > > > > For people not wanting BPF, i.e. disabling it altogether in perf or > > > disabling just BPF skels, then we would fallback to the current metho= d, > > > or to the one being discussed here when it becomes available. > > > > > > One thing to have in mind is for this iterator not to generate duplic= ate > > > records for non-pre-existing mmaps, i.e. we would need some generatio= n > > > number that would be bumped when asking for such pre-existing maps > > > PERF_RECORD_MMAP2 dumps. > > > > Looking briefly at struct vm_area_struct, it doesn't seems like the > > kernel maintains any sort of generation (at least not at > > vm_area_struct level), so this would be nice to have, I'm sure, but > > Yeah, this would be something specific to the "retrieve me the list of > VMAs" bulky thing, i.e. the kernel perf code (or the BPF that would > generate the PERF_RECORD_MMAP2 records by using a BPF vma iterator) > would bump the generation number and store it to the VMA in > perf_event_mmap() so that the iterator doesn't consider it, as it is a > new mmap that is being just sent to whoever is listening, and the perf > tool that put in place the BPF program to iterate is listening. Ok, we went on *so many* tangents in emails on this patch set :) Seems like there are a bunch of perf-specific improvements possible which are completely irrelevant to the API I'm proposing. Let's please keep them separate (and you, perf folks, should propose them upstream), it's getting hard to see what this patch set is actually about with all the tangential emails. > > > isn't really related to adding this API. Once the kernel does have > > Well, perf wants to enumerate pre-existing mmaps _and_ after that > finishes to know about new mmaps, so we need to know a way to avoid > having the BPF program enumerating pre-existing maps sending > PERF_RECORD_MMAP2 for maps perf already knows about via a regular > PERF_RECORD_MMAP2 sent when a new mmap is put in place. > > So there is an overlap where perf (or any other tool wanting to > enumerate all pre-existing maps and new ones) can receive info for the > same map from the enumerator and from the existing mechanism generating > PERF_RECORD_MMAP2 records. > > - Arnaldo > > > this "VMA generation" counter, it can be trivially added to this > > binary interface (which can't be said about /proc//maps, > > unfortunately). > > > > > > > > > It will be up to other similar projects to adopt this, but we'll > > > > definitely get this into blazesym as it is actually a problem for t= he > > > > > > At some point looking at plugging blazesym somehow with perf may be > > > something to consider, indeed. > > > > In the above I meant direct use of this new API in perf code itself, > > but yes, blazesym is a generic library for symbolization that handles > > ELF/DWARF/GSYM (and I believe more formats), so it indeed might make > > sense to use it. > > > > > > > > - Arnaldo > > > > > > > abovementioned Oculus use case. We already had to make a tradeoff (= see > > > > [2], this wasn't done just because we could, but it was requested b= y > > > > Oculus customers) to cache the contents of /proc//maps and run > > > > the risk of missing some shared libraries that can be loaded later.= It > > > > would be great to not have to do this tradeoff, which this new API > > > > would enable. > > > > > > > > [2] https://github.com/libbpf/blazesym/commit/6b521314126b3ae6f2a= dd43e93234b59fed48ccf > > > > > > > > [...]