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 08349C10F1A for ; Tue, 7 May 2024 21:56:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 801F56B009E; Tue, 7 May 2024 17:56:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B1236B009F; Tue, 7 May 2024 17:56:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A0496B00A0; Tue, 7 May 2024 17:56:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 489A26B009E for ; Tue, 7 May 2024 17:56:08 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F19C440553 for ; Tue, 7 May 2024 21:56:07 +0000 (UTC) X-FDA: 82092958374.30.133F7AB Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf23.hostedemail.com (Postfix) with ESMTP id 35E0614000C for ; Tue, 7 May 2024 21:56:06 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf23.hostedemail.com: domain of namhyung@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=namhyung@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715118966; 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; bh=nXTaPie4n8q7aWd8lKqdehPO2SNuKWmtizpezocD5H4=; b=5ZpHv0q3w5j7UpVjbdVr80FbNwzx9ofkAs0LjLunKbqb5AS5CGLTU2AqAYImuva3m5E+Qx 4//4zEbbjFJdTo2+rT/G32qon7wBblW/neQgMFq1hQz68ffyjGTwCRoE/HAv1juUJWPCR3 iXt+PGkyJR8JA5Iko6v/00EgOKKZtdY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715118966; a=rsa-sha256; cv=none; b=diZosQ4TZ+dRAT0QV2ySqBNgty79uFvZrtW1g7y3tIRGGWJr3FJW7ZNbhZQPeCgwZ9cx/o D6R1Z+2Z58Nk2dOuamORHAFFPOfPOpykRkTi6mnBqVpCBfpohWp+DXLG4nyRYIZYMxQfuC vZhC/57txxTb2ZJzT6fbs/HgKbp70yM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf23.hostedemail.com: domain of namhyung@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=namhyung@gmail.com Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-2b273cbbdfdso2628607a91.1 for ; Tue, 07 May 2024 14:56:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715118965; x=1715723765; 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=nXTaPie4n8q7aWd8lKqdehPO2SNuKWmtizpezocD5H4=; b=dAMYhjcoRYoA9AXEVknGvwaqpS0hn4JDZBwOdtJT9nDDHjL3PngDrz0W5RwTYZyVF/ MemyTc8bfeUCti8UX8eiZVeS3GwE8i45jCApgZzHsfnRJSDdyPYMmGh6bBS+aZqmeo9R OD6m21UsiDwMGRUPQpLtljDk+9JzuF9ZHUnKGd3l4p0fG8MCe+qR4+wpj5PHrNzA38TK m8V0u4D10naMBOIh9ThIfRXp54hPqWbYmethIjGCzT/EI1EOskrlvD2GEEXmGB0QME3u i5YVZKPf2lGHEzyrACTEj3sBLj8abQSvOGoGu/IR6dAex9ACeF0DpBNKbEoO6arQa8+6 sl8g== X-Forwarded-Encrypted: i=1; AJvYcCXOoCogOausOw+/8cExMq0drO2M2F62IzCInJ08ows3cqzzvzY34twcADQAHj2I89TAi2+ec6B7LK59epfANXqtGSs= X-Gm-Message-State: AOJu0YwDnXlBpxE4AJU6BxJ9MTEdba+99ehMTQI79VT8MbBtuC2smjeo CFl+6VZfGuzqMmdOW8EteKVJsCNsOnFcOwdQcIbLwk5JYRVEZ9Y/QqND7FeJU7/abtPgeV9fVKd aWF531RpqRYiet2m5VeCViKhj3fY= X-Google-Smtp-Source: AGHT+IFXpLdBXP0wh3twnNJnWEDW8JXUqluwb5PZEvCJy86sy4dMIzPSzZ/Bo27vj60SVq+hRMSHToV6/VUrIXVJVlQ= X-Received: by 2002:a17:90a:cf14:b0:2b3:ed2:1a91 with SMTP id 98e67ed59e1d1-2b616ae2ca0mr732222a91.45.1715118965098; Tue, 07 May 2024 14:56: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: Namhyung Kim Date: Tue, 7 May 2024 14:55:53 -0700 Message-ID: Subject: Re: [PATCH 2/5] fs/procfs: implement efficient VMA querying API for /proc//maps To: Arnaldo Carvalho de Melo Cc: Andrii Nakryiko , 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: 35E0614000C X-Stat-Signature: ujmkwerh4ij6n9sori5mkjwxn4dcb5kf X-Rspam-User: X-HE-Tag: 1715118966-131672 X-HE-Meta: U2FsdGVkX1/mVr9CuZ84GMecSKE/nDU97w/FMWQXxkAsqkCQkIU5NItuyqHI07k4LN0tMFCIogfz3TcwP/LzZdDJl6ogQewLyiA4rAaDWYOSIIVBkc692jP4S79gOfdLTpt5IrigBoE6M7iDG8W7jhtUJu44FkjCMWwgMGRVzOvlV4ZOS+XlCJE80NmDnIDBg0ckI/XiSskkCEVrC1RrVrL+r3ajmz40ZjCSrK9LzNdBN0aTiHbi4q68Jxdavwx7whM/GWJVrpa127zRLuBftwJrS6rb/YSRHhepLCXnRvh39O47psO2cJSjUwl8wpumIFLuvVwSC36OiFENUPi/TjLCRus5y4J2VzRpK8YRCKQm+8E9xCSGNirJrZF5c4pCdfRN8umhEDFsvUay2Z6M27a+WsiLGdacX76a8gcg2WuYGFTiGTN0uyBpqVG62wI/heDQkG52p7tInBvvQ3V6yi7CagEnbBkpTj97kWBIPqeg4vYYH/iYj4RmUqScSKef4ewMSCcFg4ruGeJmrCoUTOb9qR8mQe7QD0RRLoaZTnlpK+XRaW1wnQhSp9JM5IVfqsfsmWkS/Fi7sRWR2050mYt4ln9oMUgZ0crDnbG1TXhuSyszKMy0Yf0HHNLlgcyGC7zGItV6VYVAY4LK7dv1+Txk7xvoyKf0Iz7RDVqrlcjkRGA1mSv0lzSkAtNvsPjDojZDxJvoc/+8ak3nU7KHHezArpXR5weve0XWfvoLeUcdqJis7j5TlFAesJzL1TNk57mKClGXQSPyChCjUf05TElztUduqzWKyJ6qQ1ihE1z4IyOSWKxeaDI0RErWASd3U5GI+VHslwZ0L7JyM9LT4ywdkdOggzW+bXSM6SfC78tS5SCoKag6kaUZRKJWHPrewZwd/NjKponzbYS0APy+q/fLYL46XzFp6RUnQMee5yfs4gciAjvJCi8LMVfwLFArltXs6K+R2+rvxLRyEOS 5fVJLn18 b1RxnnWIIHfEMQCiGNzf/LhEqUX+bZfJ3P7dA8qUZofwfQxchIH2LtJUnKbhaHXYqQlVR4OQWZMk+NGUUbA2qeBw4nrG2jIptl2ELUvmwWzPapx8DlvAffCpi7hIs/J24CKvVLrLCw4YbVpH4C9K4lzEUnNADSFtS2TeNowy22PVOijr/43Q3RLN5Mdt/qBOgHfX49461lgByfqr41t0wq5mMCf90RxZDjLt7a+GFelpmJC/Os7zHqsf1251FmaK60G8r1d4DkdF8lIU5xNWvU9E+GTHNpxQ7xYqkc/87dM+WQsqqJMtSfIu5WO/zOm6NVlotouWq9e4aS29LzCs2pO5QpxOT2qZgqMGVaC/FIJ5Msc8mC4V4WAwkyJeV7fepfQonI6fymF48AqHY4J+BjfG4anmiByHtQWaE4ijcMTyE2xvVsl0H/0wyJzSmkCxdxNCvdhiKPe8GWzT2pKJmZtSUFY8oCYu2mINlhurtgUyN/rfs/msI3dRRQjUCwyf8/Vo1cQqN4ANT2pLdMwyWOJ5DiQ== 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 12:16=E2=80=AFPM Arnaldo Carvalho de Melo wrote: > > On Mon, May 06, 2024 at 03:53:40PM -0300, Arnaldo Carvalho de Melo wrote: > > On Mon, May 06, 2024 at 11:05:17AM -0700, Namhyung Kim 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, o= r special > > > > > > > hard-coded or user-provided names) is optional just like buil= d 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 cre= ated? > > > > > > > So I added a faithful comparison of existing /proc//maps vs = new > > > > > ioctl() API to solve a common problem (as described above) in pat= ch > > > > > #5. The plan is to put it in mentioned blazesym library at the ve= ry > > > > > 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. > > > > > I think the general use case in perf is different. This ioctl API is= great > > > for live tracing of a single (or a small number of) process(es). And > > > yes, perf tools have those tracing use cases too. But I think the > > > major use case of perf tools is system-wide profiling. > > > > > For system-wide profiling, you need to process samples of many > > > different processes at a high frequency. Now perf record doesn't > > > process them and just save it for offline processing (well, it does > > > at the end to find out build-ID but it can be omitted). > > > > Since: > > > > Author: Jiri Olsa > > Date: Mon Dec 14 11:54:49 2020 +0100 > > 1ca6e80254141d26 ("perf tools: Store build id when available in PERF_= RECORD_MMAP2 metadata events") > > > > We don't need to to process the events to find the build ids. I haven't > > checked if we still do it to find out which DSOs had hits, but we > > shouldn't need to do it for build-ids (unless they were not in memory > > when the kernel tried to stash them in the PERF_RECORD_MMAP2, which I > > haven't checked but IIRC is a possibility if that ELF part isn't in > > memory at the time we want to copy it). > > > If we're still traversing it like that I guess we can have a knob and > > make it the default to not do that and instead create the perf.data > > build ID header table with all the build-ids we got from > > PERF_RECORD_MMAP2, a (slightly) bigger perf.data file but no event > > processing at the end of a 'perf record' session. > > But then we don't process the PERF_RECORD_MMAP2 in 'perf record', it > just goes on directly to the perf.data file :-\ Yep, we don't process build-IDs at the end if --buildid-mmap option is given. It won't have build-ID header table but it's not needed anymore and perf report can know build-ID from MMAP2 directly. Thanks, Namhyung