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 D76FCC25B10 for ; Mon, 6 May 2024 20:35:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70CD76B0098; Mon, 6 May 2024 16:35:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BD266B0099; Mon, 6 May 2024 16:35:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 584506B009A; Mon, 6 May 2024 16:35:17 -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 3B5726B0098 for ; Mon, 6 May 2024 16:35:17 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E7A701A0111 for ; Mon, 6 May 2024 20:35:16 +0000 (UTC) X-FDA: 82089125832.09.4DE0625 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id 82C34100008 for ; Mon, 6 May 2024 20:35:13 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p7Lo4B0F; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of acme@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=acme@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715027714; 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=B/tNWCzDZA10YVTgug0idAEKUKggUsxz1vNvEN61zGY=; b=fgPD98LSrGG+JuDN5lFaLFWg9l93CdgNeNxNkfsj6oeoPJ4rRjrOPZuNCzfDAkAmPNL7zi cedusrHAxqQvHfGWQU9TOnBGUZ13uImwMcfVBXrGdj2nH94GU3YfffSqvTAi+kMITyqCrX cnNpx4BndxiCFQ6wgDHTtYrq4QqXY5w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715027714; a=rsa-sha256; cv=none; b=hfQ+FGNYoQY9ss+UepG/FP5EsCZngurynzdzGEyFICmjm1nPhhjx7UMyHNlq/cpX4RCX6y k8EhFoUUDzCZxAdAxs9RxbdY0lU38JJxMLFmRKuS0W7R5+ymimsRYC6B+mqOCdPZAKAQiG oZgFlDymOZQLyXpX85WlFXw7il3G75U= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p7Lo4B0F; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of acme@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=acme@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 11D6DCE0BA8; Mon, 6 May 2024 20:35:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67BF0C116B1; Mon, 6 May 2024 20:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715027709; bh=2J6q6pee6c+RhPyheJbTp0seb82usaTe/jFdcBygloQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p7Lo4B0FSYjHcCM/Bsy/vgbwfnsYFN1u8xq6hhk1tF2raIeVRu7efrKPanTu5Yn1h NjYWiHho9RWdhZTBnQOG0SzTY39KDPg4/pP4ZqLZHde0Yyuc57THzyFOghopzYiHFw YrP8o9I3qyMKwCoLCbBdV4IpLTBIIaqLvf9C5CXzfQICcpBjWPG1/Vj0wbzfHnYpZd BAPA99lYtXDJGphEKGjdpGFOuCOmJkwTcTy1KaeDYermM33/4dFCg7eyUgXap8D/DE xJN6P0+FTiracyjBpkwN/6lWdk6nwb8ld2iO8wYsfPybc6wPjqGlBWMbd2tGLk0skj 0OV6KwMUfMV8w== Date: Mon, 6 May 2024 17:35:04 -0300 From: Arnaldo Carvalho de Melo To: Andrii Nakryiko 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, Daniel =?iso-8859-1?Q?M=FCller?= , "linux-perf-use." Subject: Re: [PATCH 2/5] fs/procfs: implement efficient VMA querying API for /proc//maps Message-ID: References: <20240504003006.3303334-1-andrii@kernel.org> <20240504003006.3303334-3-andrii@kernel.org> <2024050439-janitor-scoff-be04@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 82C34100008 X-Stat-Signature: 8s9t3p3i9xidzjnz6qgszc8uo3yg4mfb X-Rspam-User: X-HE-Tag: 1715027713-754620 X-HE-Meta: U2FsdGVkX1/FJxXThp/VFEeg9YBy2NzS3FnzUJfKaIYo8fBdALaJuouFLhbPqXAbTy2GPuR9FppfwCDVsAhCipFUYGjCGLsDZ+Z+By8Yl3XslM47pXVqW5f/9dUTmUHKI9qU54z+0BJqrfit4EksHsHzzHD2Fk/9lWDBCtaIijXiS/RFWLOGhOkO9Gp56DPrTyudioHscxblrTOsG3ZOYpQkptYBK/4MdME3AQfBAdE8MhkoGPhyj3wHaN6B/MLC1T9n4jayi9i4ljnkok6iyHaFplbxgDVmEW7DAaC2eXgZb7WsjaBAjdXM4Oub946ivZVzsofY2ZQYxXrdC7tKtZ9Vl94bJYXDAg8UghBYVhu+Xxy7xpY9MqERYjiAm6uG3ISbkARDFCVCCxrhS3eQrWwngK+FgftvRSqDYOIwLRyqFPzu9QUxxqu44pR8eB+VWxMhCjoCCmeyknV9ww28Y31cNcL+3K7fhoucezgucdLr74+GSOtSxNwRkxRV6QWL9VaN4nQYZv1Ha3m/rjH5ZVnJs62rCQHL3Tm5yByHIEw/H2cdH1W0TwplEQKAca/lZ520rR86O9TtvYM7ZTu16SwaMqeW6CQ9mKg8l+0WabjdyfNARFR6AXHR/80Ya0e7Tya51LafDZXeOPCKRzAiCofTE2A8JEMxVmBosBxfCt+wnqYv/HFNitwqAaV6Mow8mKwnjnChnH4+rL6JZu5/ugdiZkq7emhGxFiRFVrz+T13DUL7e3+V9hlqMJ6B+YNaWPDm5dvZ+6E2PRbxsyPkFAT2eaN3wUUIcpyUCcyw/Ml7zg/lvPa6WaXnSVsSUyUAJMSTtt/pEDVIT1vBedVAExxftl9IUXBif/8qKWKRvaB8G4wb2MyvPhd+EuxxHBHd4/zsUuvx9DiwaYxVF/Nrcq18jGtt5ktpFtAHFPpd9uzAHyxv8eMfQOYVXcoTfjw9W4sgpQCdNuMU/R+YQs4 4mUokPAc 02Axt1TTZPSgYeSvlnkx+keF8tc7jXncRKji+AnlSsFM6wfxEg9m/5q0jdsea8Hit0TT+2+kFW9mwYPGb/lpdrToJdUEM7MV0AOGs7MW5sJjRHJ4s4RdeHZtAcR1HVVBaZle6EGnFIx1a5POfU6/t77iOcMlvIbqHtJD5aSL+s0hMFOR8C4sp5bjZdkeR7czeJX/7eyjsLAyKeSWs22sI2TCPOp4Flk7BqGpVLmqYWJQA6W3YJLWkt3z707UgyBGW0tHEETznmfShAKAubngbD9/JMwc/QEfYxENtqkk2D8gUwsUMtYrdq3EZ+vqITQUUDE5kO4QrWk0bJS9V7Uzi/xm4YaJicxByKTu0kz1Y/OJMAIaeIuAn3RavU7qRCRoQ9oSFCLwsuVefn3XdGEUSnjrW0F6H0It1Tl6+vTKGY9krgoY= 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 06, 2024 at 11:41:43AM -0700, Andrii Nakryiko wrote: > On Mon, May 6, 2024 at 6:58 AM 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 AM 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 retrieve > > > > > it, saving resources. > > > > > > > Signed-off-by: Andrii Nakryiko > > > > > > Where is the userspace code that uses this new api you have created? > > > > > So I added a faithful comparison of existing /proc//maps vs new > > > 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, IIRC > > Jiri did some experimentation, but I lost track, of using BPF to > > synthesize PERF_RECORD_MMAP2 records for pre-existing maps, the layout > > as in uapi/linux/perf_event.h: > > > > /* > > * The MMAP2 records are an augmented version of MMAP, they add > > * 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 = 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. > 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. > > setup a meta data perf file descriptor to go on receiving the new mmaps > > while we read /proc//maps, to reduce the chance of missing maps, do > > it in parallel, etc: > > > > ⬢[acme@toolbox perf-tools-next]$ perf record -h 'event synthesis' > > > > Usage: perf record [] [] > > or: perf record [] -- [] > > > > --num-thread-synthesize > > number of threads to run for event synthesis > > --synth > > Fine-tune event synthesis: default=all > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > For this specific initial synthesis of everything the plan, as mentioned > > 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, the > > 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 method, > > or to the one being discussed here when it becomes available. > > > > One thing to have in mind is for this iterator not to generate duplicate > > records for non-pre-existing mmaps, i.e. we would need some generation > > 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. > 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 the > > > > 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 by > > > 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/6b521314126b3ae6f2add43e93234b59fed48ccf > > > > > [...]