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 C373CC25B5C for ; Mon, 6 May 2024 18:58:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 367266B0096; Mon, 6 May 2024 14:58:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 317186B0099; Mon, 6 May 2024 14:58:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DEF26B009A; Mon, 6 May 2024 14:58:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F2EFC6B0096 for ; Mon, 6 May 2024 14:58:48 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7411B4074F for ; Mon, 6 May 2024 18:58:48 +0000 (UTC) X-FDA: 82088882736.10.402677F Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf27.hostedemail.com (Postfix) with ESMTP id AAFF640013 for ; Mon, 6 May 2024 18:58:46 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eM3/Ohrf"; spf=pass (imf27.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715021926; 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=IBmUGkhhD9gkT1EUET4z6SRcZE4ycm2GQWxqwdHtioQ=; b=ge1BbmsHeZgv93jvC+cE1+gAEOzlZ4d4KL8TOxS3kXz9Etqr/kRCFrwrzpZHXUbVIzrYlm k4zTTLyYZG4lYK+3M/9Uh2wlBKPn2qtcuHNWrhJV3ZSY767CVe1hAqSYKhadK3bZ9XZOdp QlrKS17BqZVaPJLYfWe/pS8QZdf0D5Q= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eM3/Ohrf"; spf=pass (imf27.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715021926; a=rsa-sha256; cv=none; b=pRjEx+u0ZJ/XHeaCSXHEUFyQNeJ/BKKBQiRj0JTZDsNqH3GSDhH4hXB0ABQdofEbiC5naH 19ELvL0m2qzqbPFnCSkX8U2OxGn2mMLGPBu44RzvXxAUfVZOc5IUDOAHYnGKSIAB/LixRy GD2wzkvrCMg5cSvMcCMa7kSntwuVr5M= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1ecc23e6c9dso12710845ad.2 for ; Mon, 06 May 2024 11:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715021925; x=1715626725; 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=IBmUGkhhD9gkT1EUET4z6SRcZE4ycm2GQWxqwdHtioQ=; b=eM3/OhrfwFiM2PeTZ/hnwgujZjgKPegTZ1za+o/w2VJuzLDAjo5bSyyUpR5zya+C0x IGg3Z8/Bd77s0ICsmxtGVxkhPhwk+V5bh+g9OvdqQIHW3TvB0HleJsvE5T6I7Eh1b7KH K5zHxVtEdy6ROArt4qEzzU5T3/h66ctnuoAj7oGjUw6rQ/6H88JW/QyruSCYVAg90p/F +IVe52d4b4Z4CGyvN6gc75gphz93EcqpkXBazOVyk1dcDRsmH66ucBQHCPgh73MhR4ra zsBnEgdbYjSWXmD/dBegf+PGh+KPQXcxlnpVDB8DqRmIaGJLqmMUMgwf+F+iaqV4K3K7 Mg4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715021925; x=1715626725; 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=IBmUGkhhD9gkT1EUET4z6SRcZE4ycm2GQWxqwdHtioQ=; b=N04zBlcgHMSLiwBDWEvg3SSNA/JIeSEmTd9rBqLIYT2nRgA0FiBDFOAk4/2VJvkFqi Xk+nxrLXyqJjGfaaQ0oGWuw8HMnyj3GNasr5sMsUv/x5jP0Z9j1hM/QE8qaZ4995OTpU 9K54ThinLPlx/QD8YaUOwMu8UiChDCpe4jeBu62WKQ5iParHxC7Rtr53JE27hUY0U0Rw 4BtjiD6+sWvWViEsJSaOM4tgXfk2K+JXi7m2wbvnr/Mqovy7ig03Yuv6hu/cLMv97JUy /z+IyMwKYsOpoO9RxZS5zyFKMoPrZfrvRhxSp/1xhgKavxcI5Xsa3w7/3ZOnWU73b5p+ F8sA== X-Forwarded-Encrypted: i=1; AJvYcCW7QEpgmLhKG2WGKe2Je1DDsHEmNFW1zOlrkAYT1SaEAVwJInZmWISlBFJ18STDFn6lGd0yqLBObK08SdmBJjw7Iu4= X-Gm-Message-State: AOJu0YyVfPS5MjkKaMMTRezszIs75SzFvbKvGemruAGpH50cI4Zsuh+i MHjLHfvErNmfDIHC5Z8nlcx43w4+GmD9M2yGB4gNkhKaVt9trnrtwUWZOlXuYSMzp9NYo+y6id4 CjIfITfEnM0iJMDAXJuRfoY1x+1U= X-Google-Smtp-Source: AGHT+IG2o1N2ycMIv9uEIIuEDq3uzONEVpRTFGB3VtW6olbmTd0XdQVumNZTfLPBdE5tJb2lg7+V4RRFAAwYOxwBVO0= X-Received: by 2002:a17:90a:2c4e:b0:2b5:4ee8:e5e8 with SMTP id p14-20020a17090a2c4e00b002b54ee8e5e8mr2886874pjm.16.1715021925228; Mon, 06 May 2024 11:58:45 -0700 (PDT) MIME-Version: 1.0 References: <20240504003006.3303334-1-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Mon, 6 May 2024 11:58:32 -0700 Message-ID: Subject: Re: [PATCH 0/5] ioctl()-based API to query VMAs from /proc//maps To: Ian Rogers Cc: 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, gregkh@linuxfoundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: AAFF640013 X-Rspamd-Server: rspam06 X-Stat-Signature: m3w7cbq7rneu8799kixn3gkyziuqtrkf X-HE-Tag: 1715021926-265418 X-HE-Meta: U2FsdGVkX19Q5lkGyOjEH244wsqUkNzDeSFOiJXCDURLPERISen4smMP8AQ+qwbjZnPS8n+tQJXHQMfOdF/xFV81tUXWVjSitGf0z3MdSVaDZh6TjBqq23R9BcjDKY4TeorbGjJxoPXufspQ2mj0YGq6y6eQ80k26h21+Y4AGXoSMxlLQL0LptLw3H7GSsvV1VuQGPPInFrVq4JzrM8NtNVlz05I8TDqQ5XjTh00axTM8dNVgQlAYdSOgcoE+MMQ76NUkPVei6Jh/ylhHeLDzMRHIH3nsMBSDKOPjCz/ziPIkn85FBRK+JN0ZBjYTbHg9oiZRKXjNz2qBCKY22jUIRbJb5SsSVnBW+RKah+yv8tDSKJGEntF2rM1EUQQz7d3xXWFw70GlhoZZK4DrezPzr585NexZg/RjKmlHFe2zdopIVGwFhM62Z7J5fMWuSNn42M00CTcsr1trHHMcpo+mA9Jiuvm+qIZKe2fAEhJOcJMH2XoWiCM9rh2qYPC7OrAF6YSRkUgqKxHOENjg95weFm4HYhpFwMwnfH/6SD+TPmDcNRB2WhTI/AD6TMO44gzb5LpySIossbZ70Or2HOE4YhVy3adXJquSZaq70eGSubCLJIulcxoDshWcFptizKiioQozmomj6hxKTVomaNm3AA6X6VuWJ8xO3Nqln2yjj1DL9DUzzhfSajxb5uvzUUOOHjiKBrCDGH0455MUmskoRrLoIF6i9tH9Ch444Lo05m3BHUcIKGsKKiZi/7YfuYrWiGI4Ka3KW3rTfkcLlTQ/JmZji4qxaxxQGkVlTgB/ChV/Bb87OtJELShI4MmhgJChCeaxa8sDuNWwRYjdtnf/QJfXNvs1GNqOHF7wfFdkIkdXoSVxgOKvaF7yz8k2+y5y7E9qKkUs9VH+2ZJpA/iNxPO82/At4HV0T8sHLt0SCRzRXpCNEq2ogpEeO7aYzasmPuDtgbhXUAB03Ifta6 pafdjgNt KtRWx8G64WBpsnYV5AjmjJTHmPKk0zim9DoeCENUueNQz5OrrFia+LInyKq7jCGCMzk7NbAzQCcdNILVtsc3zPg4IXiWbhS/hshqPgEDcJ4V2nCinYPrFjBIffFMGQVIvNCpSrlqOAtVtrEYu1t4gqp8Raf5ROwTY48REtdEKsyD0KGxoVZdI4vOWKCOL/oqleUwbh1kw44PeH/fYug01FK7fw4FxZJ7BiGLjeFw2GvKDrcURsFjvzTsjUoG8iDzUN3XsDrcvAhOcXSInQ3O+53TibyfPmUoN+vn4V0Yxw1vMOd5uFr5ETK36/ERb2K8SJRkqRcrjCaWYkhy0vCveKLIkDJ+j3kMHTEi/dcqeVOuf2u1QAkJsj49bwJyNaMhMv6yj/8R4jQUlIbeHn1hlgnZrV2HRCAXZRdQpQA7dYwGFNZk5dV7mobXFM+RGg+S0yYEDtP4UV1DsSHICy04PP94M/Q== 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 Sat, May 4, 2024 at 10:26=E2=80=AFPM Ian Rogers wro= te: > > On Fri, May 3, 2024 at 5:30=E2=80=AFPM Andrii Nakryiko wrote: > > > > Implement binary ioctl()-based interface to /proc//maps file to al= low > > applications to query VMA information more efficiently than through tex= tual > > processing of /proc//maps contents. See patch #2 for the context, > > justification, and nuances of the API design. > > > > Patch #1 is a refactoring to keep VMA name logic determination in one p= lace. > > Patch #2 is the meat of kernel-side API. > > Patch #3 just syncs UAPI header (linux/fs.h) into tools/include. > > Patch #4 adjusts BPF selftests logic that currently parses /proc//= maps to > > optionally use this new ioctl()-based API, if supported. > > Patch #5 implements a simple C tool to demonstrate intended efficient u= se (for > > both textual and binary interfaces) and allows benchmarking them. Patch= itself > > also has performance numbers of a test based on one of the medium-sized > > internal applications taken from production. > > > > This patch set was based on top of next-20240503 tag in linux-next tree= . > > Not sure what should be the target tree for this, I'd appreciate any gu= idance, > > thank you! > > > > Andrii Nakryiko (5): > > fs/procfs: extract logic for getting VMA name constituents > > fs/procfs: implement efficient VMA querying API for /proc//maps > > tools: sync uapi/linux/fs.h header into tools subdir > > selftests/bpf: make use of PROCFS_PROCMAP_QUERY ioctl, if available > > selftests/bpf: a simple benchmark tool for /proc//maps APIs > > I'd love to see improvements like this for the Linux perf command. > Some thoughts: > > - Could we do something scalability wise better than a file > descriptor per pid? If a profiler is running in a container the cost > of many file descriptors can be significant, and something that > increases as machines get larger. Could we have a /proc/maps for all > processes? It's probably not a question to me, as it seems like an entirely different set of APIs. But it also seems a bit convoluted to mix together information about many address spaces. As for the cost of FDs, I haven't run into this limitation, and it seems like the trend in Linux in general is towards "everything is a file". Just look at pidfd, for example. Also, having a fd that can be queries has an extra nice property. For example, opening /proc/self/maps (i.e., process' own maps file) doesn't require any extra permissions, and then it can be transferred to another trusted process that would do address resolution/symbolization. In practice right now it's unavoidable to add extra caps/root permissions to the profiling process even if the only thing that it needs is contents of /proc//maps (and the use case is as benign as symbol resolution). Not having an FD for this API would make this use case unworkable. > > - Something that is broken in perf currently is that we can race > between reading /proc and opening events on the pids it contains. For > example, perf top supports a uid option that first scans to find all > processes owned by a user then tries to open an event on each process. > This fails if the process terminates between the scan and the open > leading to a frequent: > ``` > $ sudo perf top -u `id -u` > The sys_perf_event_open() syscall returned with 3 (No such process) > for event (cycles:P). > ``` > It would be nice for the API to consider cgroups, uids and the like as > ways to get a subset of things to scan. This seems like putting too much into an API, tbh. It feels like mapping cgroupos/uids to their processes is its own way and if we don't have efficient APIs to do this, we should add it. But conflating it into "get VMAs from this process" seems wrong to me. > > - Some what related, the mmap perf events give data after the mmap > call has happened. As VMAs get merged this can lead to mmap perf > events looking like the memory overlaps (for jits using anonymous > memory) and we lack munmap/mremap events. Is this related to "VMA generation" that Arnaldo mentioned? I'd happily add it to the new API, as it's easily extensible, if the kernel already maintains it. If not, then it should be a separate work to discuss whether kernel *should* track this information. > > Jiri Olsa has looked at improvements in this area in the past. > > Thanks, > Ian > > > fs/proc/task_mmu.c | 290 +++++++++++--- > > include/uapi/linux/fs.h | 32 ++ > > .../perf/trace/beauty/include/uapi/linux/fs.h | 32 ++ > > tools/testing/selftests/bpf/.gitignore | 1 + > > tools/testing/selftests/bpf/Makefile | 2 +- > > tools/testing/selftests/bpf/procfs_query.c | 366 ++++++++++++++++++ > > tools/testing/selftests/bpf/test_progs.c | 3 + > > tools/testing/selftests/bpf/test_progs.h | 2 + > > tools/testing/selftests/bpf/trace_helpers.c | 105 ++++- > > 9 files changed, 763 insertions(+), 70 deletions(-) > > create mode 100644 tools/testing/selftests/bpf/procfs_query.c > > > > -- > > 2.43.0 > > > >