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 619C1C6FD1D for ; Fri, 17 Mar 2023 16:33:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FE966B0075; Fri, 17 Mar 2023 12:33:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 987DC6B0078; Fri, 17 Mar 2023 12:33:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 802A96B007B; Fri, 17 Mar 2023 12:33:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6E7936B0075 for ; Fri, 17 Mar 2023 12:33:33 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 33FE6C082C for ; Fri, 17 Mar 2023 16:33:33 +0000 (UTC) X-FDA: 80578935906.19.9086B65 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf28.hostedemail.com (Postfix) with ESMTP id 52355C001F for ; Fri, 17 Mar 2023 16:33:31 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=npLaYxhq; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.44 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=1679070811; 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=sOc1064wJwVxntbc0Hg4Pm5Z8bh8eNRp/vDpjqeTV8A=; b=Bf3TwJMKRpSy+6QotXJNOhSko1nkauT0Xp1m0+bDXXTiNqLdqc+ystgyv0jTWAk4LbElw9 Bkqe6vkGVyXzOT1eA5hcOdMvf3pnIKPSXqrJaj5Tq8hZuyxt9uywrWiLlAZjV6xNfS+1RV tpsIMoFGZVRy3z3XfAtH46UBEB49bGI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=npLaYxhq; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.44 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=1679070811; a=rsa-sha256; cv=none; b=WUHqgoDk+yVOCDiMbwIUs2eP1qvthfqX+Ntou8QlmQm87Arnctu7Wf8zZ3f5YRpqYfyNQu lHKCU0pQ5i8rpnOYBN6BCitXuxtayGFdvlcKGBplT5m7Hz1YqtiDIuP6J1X+JEDwhVLeS/ MXFZRhGZ/FmW4Kl+YbmRKkBUqlvLcO4= Received: by mail-ed1-f44.google.com with SMTP id fd5so22617709edb.7 for ; Fri, 17 Mar 2023 09:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679070810; 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=sOc1064wJwVxntbc0Hg4Pm5Z8bh8eNRp/vDpjqeTV8A=; b=npLaYxhqDOo4k6OjTdGIDQG0WQfkgtv9fM6BdKrkgn40eFBPLGXHs3yWzljccmyqFp 9ZPFV+7u4iptswc+firC3lJ9YhcygL+/3eHPtfo5wxoGAuB4gYp2xWIsUES5cUTFkq++ xz8PToZXfHlOeG7TmrhhOx53Nog+9wC2ylbmAmjZmwpEN170qmKZukfxhjUX8GuEyda9 nJ8Vns+osPqA4HvBdp+PUjkFpCKf/cu1P/jPkbynrcOTe2VmLIAaObRntsQY90dkhDaY cqg/85OMC1OnxVBzE8PYrjQwnyNgcTf7/05NJ9SZNG0+tn97Fo0kTnS/LwY63/7nMi5p 3P0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679070810; 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=sOc1064wJwVxntbc0Hg4Pm5Z8bh8eNRp/vDpjqeTV8A=; b=s4lvunEGb1GF/mCXOxp1tV0lc2p3EKjih4SBGUDgRxgJKuiNfarcUa51/lA4Bj7Gvc peJ/jfBptePLvTks9vRroybU6aPOXzVUcWXJNf82Q1hLvtoqyydQh0UPl0QuIebnRbq7 faflYixfims9z22yg+NRm3nge/fJYMvvleWOjoHxDxNmPKjrTNoPsKdzqdhk/NyGkjZ8 ru8rx1mJ6x986Hb8l19g59wf02CGjcszi+TVBNebDyTdvFPQa99ZkBtF3/VpZmNjaeSp QQ7y9if64Mwf/vpbxY3OdWSrld6jRLSPLqHWdFZjUDCFa/peODhxxcGtQ0h3C5tyN5WF t0sw== X-Gm-Message-State: AO0yUKU81lT7yEmEi7N6z1ns4dXvY4+94ga5uGfvE+DJpVMtYvJHyzIB XJwoLy2t3GOidVMu8zWvmJYPyUQXzQFiCm9p6tM= X-Google-Smtp-Source: AK7set+0ohyPqN6E5Ro9SkqCqggHHZv4+NXE5j4GuR8AQ+M1h80H52LGa3htbnGp0mJWOjTgUhvmwUwf1sMfqR3ewCU= X-Received: by 2002:a17:906:8552:b0:8ab:b606:9728 with SMTP id h18-20020a170906855200b008abb6069728mr7694310ejy.5.1679070809653; Fri, 17 Mar 2023 09:33:29 -0700 (PDT) MIME-Version: 1.0 References: <20230316170149.4106586-1-jolsa@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Fri, 17 Mar 2023 09:33:17 -0700 Message-ID: Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object To: Matthew Wilcox Cc: Ian Rogers , Jiri Olsa , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann , Namhyung Kim , Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 52355C001F X-Stat-Signature: f6rh69mks3nfyth349ap8o91wpqcjthy X-Rspam-User: X-HE-Tag: 1679070811-611409 X-HE-Meta: U2FsdGVkX1+0/0bSLI28UigSCuHZkZaJX00hzRhdEfIdnMElTdGIhgIQVOdUDmatvUG7ttR7XvZ4tR2rY+3xiqr1DTLg9MiJ3hzRPHXR34v7fbmE3FspNw4q+VvHfK6hAplv3HMRZtZpgiPjQRFVrVqd8B5oLe6+3Mm53oRmhG8ZksGGxNvKIwaZybXliSGgmR9DZzvummrlZCLU17UaDUTB8Y/1FGZ7cfrJSgY+6erxxdE5jvK+Ch005WESVCAZUQn3AcE6z31G6hSGiqty96MpP8RNW4JbZ2lWrgL8Hw6CYVHaCUQ0oDLAOgvXkG7BhkMONezZJeKwCKD4x5Am/cK+s/W7tyByIdxOdxR7Yzj9dDDnOMRVFtAT8KMhC0pzSox0VJ8/di60mcD+C2c7qUKOoORKQsk6e9hbhqFVjoKmePTOoIkjxyIVqKaw3br9cXYlgdPS1gszD5bx7WXrHGMPmTMc3HgfDKcY3Nu6xZqMRubjS0xLtRJLuBHliU7k7c75tgGj8hoshtRlwTPEw1UKkK6mLzMFFYQSaueWdCmg8uNPrzH+8ZflEUJtJH3X5rMjA3a0TswSGLeNMOLy8tmZjgjHB7cJTu/YVpiI8Dx0ldq7804ymWYvcTFMeKEl/12rK/NLkIomybwDMZpp7o+F2SRphToOa2od7IwpTA76RbOdcGEPc7CshiimfSp8ddJp15+j9cEQgUZQ1qA1obZTsEhcNfzrSf1MVXRTtjFMOJUbjncGP5OiMSv59k+6jQ4Tj8wn1F27T5ZjIEqGSkg30xyyUkvIcne56Fx3uepRyS3fzEsPRk4xhshx6ThYD0vufZ3VgdaUtsH018LarDH8NAje5twGrdY+Ki683OmetY/GIkcbKqLq9cLoSqWzFZAvVvBz+RGboygevohP0+5Ae2zjli4lgbM1n8lnVGJzkPkK5qytCk3Ov0rM4t2+86B2u5Z8aPdkuWCE0Yw 9vNlQmsc MoactfB8bqP87nd1A4Gphr6zVH5AFFJOtoFg6eX6Mesy7EXG1Twgal4X9aK+6SkA5R+QMNHCYkEvoML3XFnmASaTGyHx2k/PiXtElD4kWis5Ac7VqTteQ91zwlcS+VX7bsryWTvCTS+KPVZ5MKi2vjcbfD4mzGiUtZFwqnFx9bdOTymkre/udZRbtON+Fkghey4yIvSN9COgHIKIVyrULNlVnEZ/nZhjyipy4xPSyTozyJj/TuKLANOCLGCqX6U1sp1brGauI5EX64OvQgjnIW2Bj0F6Asp6WgfKjB7Lec4kZEOXocTX/e6+xlgLbIlCda3IVW9eKJx+vEzoFjAkdUqfi6FW65t+Ur0Y1HHO36DZnTaQHh+pzYAt/Q4tYzyMoj7dWfojToo3ubjTTAs+nSDx3wi5c69PVXKBZ86YnkhJllms+c+1KiH7mFH1YnmOz4iNbmAjbXf0wpFzcQO/Bd7b32GtU7w4MNc+C6eg/7ZQ55Ag26E87JfD+PoW23jI3zv5f4LypKY3D0Nmxs0AH1m9x7A== 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: On Thu, Mar 16, 2023 at 8:51=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Mar 16, 2023 at 02:51:52PM -0700, Andrii Nakryiko wrote: > > Yep, Meta is also capturing stack traces with build ID as well, if > > possible. Build IDs help with profiling short-lived processes which > > exit before the profiling session is done and user-space tooling is > > able to collect /proc//maps contents (which is what Ian is > > referring to here). But also build ID allows to offload more of the > > expensive stack symbolization process (converting raw memory addresses > > into human readable function+offset+file path+line numbers > > information) to dedicated remote servers, by allowing to cache and > > reuse preprocessed DWARF/ELF information based on build ID. > > > > I believe perf tool is also using build ID, so any tool relying on > > perf capturing full and complete profiling data for system-wide > > performance analysis would benefit as well. > > > > Generally speaking, there is a whole ecosystem built on top of > > assumption that binaries have build ID and profiling tooling is able > > to provide more value if those build IDs are more reliably collected. > > Which ultimately benefits the entire open-source ecosystem by allowing > > people to spot issues (not necessarily just performance, it could be > > correctness issues as well) more reliably, fix them, and benefit every > > user. > > But build IDs are _generally_ available. The only problem (AIUI) > is when you're trying to examine the contents of one container from > another container. And to solve that problem, you're imposing a cost > on everybody else with (so far) pretty vague justifications. I really > don't like to see you growing struct file for this (nor struct inode, > nor struct vm_area_struct). It's all quite unsatisfactory and I don't > have a good suggestion. There is a lot of profiling, observability and debugging tooling built using BPF. And when capturing stack traces from BPF programs, if the build ID note is not physically present in memory, fetching it from the BPF program might fail in NMI (and other non-faultable contexts). This patch set is about making sure we always can fetch build ID, even from most restrictive environments. It's guarded by Kconfig to avoid adding 8 bytes of overhead to struct file for environment where this might be unacceptable, giving users and distros a choice.