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 78543C6FD1F for ; Wed, 22 Mar 2023 15:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5EF56B0071; Wed, 22 Mar 2023 11:45:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0F3A6B0072; Wed, 22 Mar 2023 11:45:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD6FF6B0075; Wed, 22 Mar 2023 11:45:17 -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 AF6B66B0071 for ; Wed, 22 Mar 2023 11:45:17 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 43CD21A050B for ; Wed, 22 Mar 2023 15:45:17 +0000 (UTC) X-FDA: 80596958274.22.0316F27 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf01.hostedemail.com (Postfix) with ESMTP id 33B6C40013 for ; Wed, 22 Mar 2023 15:45:14 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPTMOF2Q; spf=pass (imf01.hostedemail.com: domain of acme@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=acme@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679499915; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rJ+ruzyoZoYnM24UAkIZMOn1rUXDskR/2JzFDQXCtGg=; b=E5KNUlX6yFW8r5inA+kHkggRPw/n9R68Muu7ubrkQCjG/gZUcZ+S99PsNTSAGWy31fU5U2 L8d/iGV05+zEjxLJ26fFmS6V/OWf7bdo9NRCacrXHRvTfbDBa3JfaTh0C+EQQLbp2dBNCk BgzZJOkmfZeQss+YxOJy+t4egDpEpnc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPTMOF2Q; spf=pass (imf01.hostedemail.com: domain of acme@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=acme@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679499915; a=rsa-sha256; cv=none; b=cZ3oKBSEYowxsFLkYFnX/6twTi6nJv8pY4yF/WD76d0/rQPfKuk/HMEmv1TVGKmmOiQJAk upu43A3HYp0iLt/gi6QtaDFe/rlXRIjWib+rAi+RgeiRVqYu+2rCwr/A9axAPneIHVWQbf XyKSorEFnni+mEqxgPXrcIMrWCGr7uA= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 21321B81D3D; Wed, 22 Mar 2023 15:45:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18DB4C433EF; Wed, 22 Mar 2023 15:45:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679499911; bh=piznudyQ7uqbaBZcF98HpIF4CU1dBOZ+wPLdqX0TKmM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GPTMOF2QYze+8g9op7JZXCl4pxzpbiXWubKMKya6NKMfPPSCGp43Ffx1kefd5rQuo 9VFqJAAQ86YK7t4MJT7ii5MQZI6E45Hj5aXg3fFcM+34JVAE9bTrAsbKLA1GJYdO3E GScOT5p3bPBNZtrVCqkEgiljnrgsSeGJWISFVGz3jfgJY7pEh086t5cdx38iyjHN+g KlPygj/UDC31vTBV0TBtTOCYsv5z2VvPQ9utBCNF7EdgoHzNWSli5J5mGyOw4tMVEL 3dnojFfiV/VvdOGIChvgg8ax/1pfu530QH3LG7iRqJcfiHsMbkxf/mJpe+qAgtPBnE mrNf2qH8OPv2w== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 4E5E34052D; Wed, 22 Mar 2023 12:45:08 -0300 (-03) Date: Wed, 22 Mar 2023 12:45:08 -0300 From: Arnaldo Carvalho de Melo To: Matthew Wilcox Cc: 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 Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object Message-ID: References: <20230316170149.4106586-1-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com X-Rspamd-Queue-Id: 33B6C40013 X-Stat-Signature: ihszcorq7ntpqcbgf3uinpf66nh7i188 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1679499914-45606 X-HE-Meta: U2FsdGVkX19WflpsrA9bd8yvA7MM+TaDYwFeGrHWKs9VtHBtsa5viXemW2wbBBj/E2Gw7zFnB9AnXNY2MHoRPx/E8A0kyg0J+Vv4x4QWbT7k/fQEKspIewoOBP5Ayadjsn1TYJI9a9cz+upts4i5y8YmJ8Ia9IFZdK/NJ11KmlM2fFRxf6xkiECbcKN7C1QeGGqOdtH65lY/lVAZvFqbCH/C3BNhbXmel2sMFeeemHMrx6yKQJSSBi8FAgx00ryPEtCYEI2vyKhp44t1NSAWPQu/+85bTAWLcywF48vIYqpWBdnnMs0ObSy9nStEyqPQ/BYhbRIBvAk/NFVMAO+dYFeCOibXq4Y85MyJ5MgpqF2VVnSpLRmK5jo9DgdV+j8x0NzXVrleU4k2RSfQuiU248D0Ungsfs1y5L6fvNVXxqCXnf1sS4wh/ogaT/UijxKWWUaTk/CrA8V5bKUcR8WGr1fbzm8L4xH/ID6RtqV5Uyz+uPvTj7KmUaoYRIbqH5dp09qWNggflG8tICl5BMTdDAbwSfuk5JaZCWEqwXrna7NaxLO7hOfS4F5DWu/MAMXsVZyvRzro7eno23P/Dfqu/ZpKUzQLIZEHphJHsew9h8uAf6yBo8YjBDjbUqmLNkX+DlrpKDhZCwp4zRfXR2IlRxG+BasnFNyt1kZgHO33MhAGVx5qJ0EWeM7SzA12np01yTk/ftbfyZtDXjz4SXL6pGPWfF/wUV3JuSZGMwNFrL5sVyIW61f8qokf8dNVHmnBeAL6qx3L35oPsiGuF5foZaAD5SxkuOBUFfOT+GmiGEPk/vE21FKoQZeT8Ujv5yPH/29HEPTGlxDJAF4Tscl42DBl1s5conefFf4wJdELRtGOF5N1o2pE9pM2jPJybfJ2L8OoR4N10FofmXx7t7HMz+DPxEz3u233k7cffePOQTJw8ruutfnBPZSjGxRj8x1ONQspztpya0Amhwz01Xt jxxtUqae HNueYdOqhDhpXYGJF9OliKWIsb91l3tHaCpjfPEJZDwes7tcyyiVOK4AK/XzXpVkD7he+qDxQ2aaw0EnOlKmwfWvbOLdrKsgcetT06stBywJl5/Vc4AAdUO6ip4h2w8S4bDIv5HT64AO3fYEpDA2j/To6RkgLR4Pm5Cok3+ni8ORK4eBeAHE21rWU4ZZV6TYqfhnmi5pIYGkOUeNoWjNoO/JAb0nnT59GW4ZlOdnZ0ycvwwWzBuMMChWOWv4/9gumrr5sdUX1iTSyHCapShpj+WUDDQ== 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: 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 asked: > > > > > > Is this going to be enabled by every distro kernel, or is it for special > > > 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 = kmem_cache_create("filp", sizeof(struct file), 0, SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL); 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:36: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? 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? - Arnaldo