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 E697AC76196 for ; Fri, 31 Mar 2023 18:20:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F0AB6B0082; Fri, 31 Mar 2023 14:20:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A0D66B0085; Fri, 31 Mar 2023 14:20:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 568D96B0088; Fri, 31 Mar 2023 14:20:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 442E86B0082 for ; Fri, 31 Mar 2023 14:20:01 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E3B051411B4 for ; Fri, 31 Mar 2023 18:20:00 +0000 (UTC) X-FDA: 80630007360.20.4139946 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf21.hostedemail.com (Postfix) with ESMTP id 063AD1C0004 for ; Fri, 31 Mar 2023 18:19:58 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Gw584kuB; spf=pass (imf21.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.49 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=1680286799; 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=ptCDsCZ9M1AP2auqMhwxD2e0Wct9w+HUGpQl1ZXGBuE=; b=cgRcottHueDPuRH50xTwEI92pcLU4VreAMqNWZGdNzP5oUyBHMTc6IxeKDHkbDX63J5i1i fiB1Bz4j1n5fHX9LtiJHplhEFKmA67BGXPJTW+08nKAANzXcb7R+fbWPq4d+R5jDtG2o4i rA9KOl54lZ4siq6kV6h4x1sOnx/OyzU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Gw584kuB; spf=pass (imf21.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.49 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=1680286799; a=rsa-sha256; cv=none; b=itDfilqu7MUMWO+sk8hy9jNb15Jp2OML5YMezJxWknFStcyzGiK99waeHl7yOvkBLvewoI d1rprtU1v2+sw7APdW186yHQoUW6FP4OSi072Nzllj2ZzZUwQPbZweOPZTZ6GHEAFkxabu p2VytXItFT8/R7Hu/+N4iwEsI2EydGc= Received: by mail-ed1-f49.google.com with SMTP id ew6so93046487edb.7 for ; Fri, 31 Mar 2023 11:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680286797; 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=ptCDsCZ9M1AP2auqMhwxD2e0Wct9w+HUGpQl1ZXGBuE=; b=Gw584kuBZB4NgIUzfMojlADjttI/sZS9NQ+lUHsKb0GpFWzrCiX5KxgPEM6YM3wfKb L7qyK+P8fd+4VG+CXmujXlxC7BXlewyQ8+k2Te9ebzk+rMzpahTWnav1kHCwZ0u4nDMK qSYzdA+/2PNTicJltJMZRFMjFud3XUTM6iTecSpNvUfmcC4NBDmoiTEsW6VNG4voh0Pl Dd3fimhzfdzOlXUg1Eycw8horsLfQpEwQdTlxhLhd1mTanssQvPjrFvkfEsYOGyq/O+I O9I5u9eAGOgFNajpeowt/EpJIH9cYLLO3sQlQulNKMqZZ9G9hP2k4+Rc4AmRLMzBFnll /QuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680286797; 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=ptCDsCZ9M1AP2auqMhwxD2e0Wct9w+HUGpQl1ZXGBuE=; b=ojWpoRT9F4Q02c5UpO7xAlf10AAWT5wMNmsTV6Hmsi1S0pNy3rh0a882QwsC4AqZtq SwRgHvmlqNqGfWuzrdm1VN8WHOlk+zIbKWGbQA+hqGGm++p1bbPo6qvb5CtX4bDSyh5K Wf5TaVoflyx2aRfS91KeNAJJgjf7BAGbH54ewdtzxnsz2a53zvBgo4Qmabt3n1pufLIp /wzdM7SWgIPVuhk7tNA5DuTAHy/OzYMiQ2LTZrJVdRqrTdkSP86nYJmo7LcFCTeN7+Ae InyMKGQO9auGf+wMf+HfW1g55gkpDuMsoOXifmZhARJwll+L/43IJzqSOBCUAJ9meaJu btKg== X-Gm-Message-State: AAQBX9drymzmqsxN0yIXxxHQi5ZkibjMD+jW8g4K/OifNZzkoZdwSeDn 4iSPvS3l+IiUQ5Dj9mcW9PzQvN7ZtPduzF1MCfU= X-Google-Smtp-Source: AKy350Yj+IgRzl/cUwZ8ZsG3CzqlZxtGxVHdl50ppqglRAoEyoUXrbm8X7qBqemI62LpK7yLYFn/NsSgTus1uzv5ngw= X-Received: by 2002:a50:d694:0:b0:4fc:f0b8:7da0 with SMTP id r20-20020a50d694000000b004fcf0b87da0mr14424020edi.1.1680286797322; Fri, 31 Mar 2023 11:19:57 -0700 (PDT) MIME-Version: 1.0 References: <20230316170149.4106586-1-jolsa@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Fri, 31 Mar 2023 11:19:45 -0700 Message-ID: Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object To: Arnaldo Carvalho de Melo Cc: Matthew Wilcox , Jiri Olsa , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , 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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 79trdmp8hkbdunig1i8xqs1cymif8hoi X-Rspamd-Queue-Id: 063AD1C0004 X-HE-Tag: 1680286798-858333 X-HE-Meta: U2FsdGVkX18GDccTWAyxrsmEn+mD0FhXMl4KejPSYMcJ/KZuEKYwYfTo+0bN2B637Lj9fRxpVC8oXi1DplFMHLG8fxt8gMB6NJThBaPA41Tiq1BYzIEdZQszfMunN774fK+xbqd5XYDBPCm8rKi1gjRrSiJ9v2pIIyYTgZVVN3SAqqRlML524OGcpIccF+nb8tlHoihJrw35L6xXtn3u7v9jFpJ2pKwYNmOZnMfpvqwx8M+mv9cf6HIdE6oREbxY9/d2Ortz0inh172ML8VfLwtjLcx0XBQEpgsrLL8xOSq+mfKOUmfgx9kfCiofqp2rpoHYbgPW4Q4WLT8UNzvBvv1Q2B8sVE/gH4Zg/5hq7aAlGzNsER5lWjEmuWBrhCOWG4JPV1BmOdTG2kUgpNnZTOoEtQYvIInXmdf3T5CmRk817Q89TUXAVHvtydxQpnHlqoTHTyhduP+XqXPCZDnHp5ixlXQKNWmWIprJIa+BQ/QNE8QLefMAOeELxqmlr2da6R5JpSiZhw8IRT+JzVVFNvn6QoZwH4n9XQdSmKvwKt3eJdZHA+GRmEpZtlGifCr5+PeOgDPXuRs49QW4KePXqAU+7hlVIb7Wp9K6/oQ8K0FQgsfltlT4RkjekY5RF6c4SEsLvpUDzMfGk05vBt0H62/JAZAz3EaYH2riUicqlT3YVyY5i1LwwPosldqxerQYBvh+73E/qqcScBcs87uXpPUQiEEHwHK/smb62W5mqXeRrDYhWE32Kv1k3X8baiS2yNejC6sRRWf+Yp5yqQXBH8j69xcB7AV/4DsA2PJW1H2WQjNLt2lwZFsTzuPtyIcFEoFRR+9Ar/2fMDghG1Dp6O1nNAuDspfbjzgp2rU4dNluRBVOv3ec0dXU3QQcJbXLhsEXaQXX+YAe7NSezIjLBsZ3ShOJHIlnBzy0ytoLkyHDmcNil9/yiH7rGQnI9vFDmp4Az6JTm52eQngmpKV pwZH3Zdj is9lYmGko9zoQBBl7YBZmBrNRovxLQn2749K09CFz2JDXmya2P9MAHbNbRd+7bSQdSbjl1FaI/uyF4n7XISKBTPHYuNdWpS6X4oR4xS31PjTrIiOCksx1PFr7krYqNBvSaRqWQ5ep9TCqIsM2vjG3jFCFnpnpiBWEjV9S0vsl1n56heW7aitgttDDVRM8p4wG4qcdgGudB3pm662aHxJVZ6QOElMtAM+fgMfSlIgVuA8JuWTOdXE3jwe29TMcQEUMDspOZCKvpskCsyEvAXWt1T1nJIkLCtgvs7DgbuhApR8hbrBiYURgVT3I6HI9r65F93gCiOMPWR9srmSVMa9hC5BUtVTb5QQ7QDNp8U7rwH5kQuEOE561L8o/7dCvelzSprIvLGnkXQhe6mYHz4oqiiiVu0RoCAhIlpnbW7JrA65fq+cwPsOeQgmNrx265/f16vIG/W+lZmYX9KGiFqr/pQxae78zABf1wmhFVDQqxELvEGTludJ1mgv47kEM7X+kTP5QExujqjpiESF5ko8NGRUFtpsKU369tUdvieCkR/PfwvteFTUJxAKCbtnffiRlvFXv 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 Wed, Mar 22, 2023 at 8:45=E2=80=AFAM Arnaldo Carvalho de Melo wrote: > > Em Sat, Mar 18, 2023 at 03:16:45PM +0000, Matthew Wilcox escreveu: > > On Sat, Mar 18, 2023 at 09:33:49AM +0100, Jiri Olsa wrote: > > > On Thu, Mar 16, 2023 at 05:34:41PM +0000, Matthew Wilcox wrote: > > > > On Thu, Mar 16, 2023 at 06:01:40PM +0100, Jiri Olsa wrote: > > > > > hi, > > > > > this patchset adds build id object pointer to struct file object. > > > > > > > > > > We have several use cases for build id to be used in BPF programs > > > > > [2][3]. > > > > > > > > Yes, you have use cases, but you never answered the question I aske= d: > > > > > > > > Is this going to be enabled by every distro kernel, or is it for sp= ecial > > > > use-cases where only people doing a very specialised thing who are > > > > willing to build their own kernels will use it? > > > > > > I hope so, but I guess only time tell.. given the response by Ian and= Andrii > > > there are 3 big users already > > > > So the whole "There's a config option to turn it off" shtick is just a > > fig-leaf. I won't ever see it turned off. You're imposing the cost of > > this on EVERYONE who runs a distro kernel. And almost nobody will see > > any benefits from it. Thanks for admitting that. > > I agree that build-ids are not useful for all 'struct file' uses, just > for executable files and for people wanting to have better observability > capabilities. > > Having said that, it seems there will be no extra memory overhead at > least for a fedora:36 x86_64 kernel: > > void __init files_init(void) > { > filp_cachep =3D kmem_cache_create("filp", sizeof(struct file), 0, > SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, N= ULL); > percpu_counter_init(&nr_files, 0, GFP_KERNEL); > } > > [root@quaco ~]# pahole file | grep size: -A2 > /* size: 232, cachelines: 4, members: 20 */ > /* sum members: 228, holes: 1, sum holes: 4 */ > /* last cacheline: 40 bytes */ > [acme@quaco perf-tools]$ uname -a > Linux quaco 6.1.11-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb 9 20:3= 6:30 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > [root@quaco ~]# head -2 /proc/slabinfo > slabinfo - version: 2.1 > # name : tunables : slabdata > [root@quaco ~]# grep -w filp /proc/slabinfo > filp 12452 13056 256 32 2 : tunables 0 0 = 0 : slabdata 408 408 0 > [root@quaco ~]# > > so there are 24 bytes on the 4th cacheline that are not being used, > right? Well, even better then! > > One other observation is that maybe we could do it as the 'struct sock' > hierachy in networking, where we would have a 'struct exec_file' that > would be: > > struct exec_file { > struct file file; > char build_id[20]; > } > > say, and then when we create the 'struct file' in __alloc_file() we > could check some bit in 'flags' like Al Viro suggested and pick a > different slab than 'filp_cachep', that has that extra space for the > build_id (and whatever else exec related state we may end up wanting, if > ever). > > No core fs will need to know about that except when we go free it, to > free from the right slab cache. > > In current distro configs, no overhead would take place if I read that > SLAB_HWCACHE_ALIGN thing right, no? Makes sense to me as well. Whatever the solution, as long as it's usable from NMI contexts would be fine for the purposes of fetching build ID. It would be good to hear from folks that are opposing adding a pointer field to struct file whether they prefer this way instead? > > - Arnaldo