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 44509CD1284 for ; Thu, 4 Apr 2024 23:01:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B76CD6B009C; Thu, 4 Apr 2024 19:01:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B26F26B009D; Thu, 4 Apr 2024 19:01:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EF096B009E; Thu, 4 Apr 2024 19:01:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8044D6B009C for ; Thu, 4 Apr 2024 19:01:03 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4608B1203DE for ; Thu, 4 Apr 2024 23:01:03 +0000 (UTC) X-FDA: 81973371606.17.C63F8F8 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf27.hostedemail.com (Postfix) with ESMTP id 97AB040008 for ; Thu, 4 Apr 2024 23:01:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=RjT1djYl; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712271661; 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=KHLNB8rkpoKwDhM7NRf7iWUfLDgvBLjzklimu7mkdKs=; b=YueVt5HiYNMuG5ly0vQRd6jS6094Bn4tOHK94WWv5C0oRjGwUCoKrHaYywxL937Eml3dMK YB6u2d1ysYFQCGgx3j8/r6cmoQC9nUVz1zwiIkueFvRTwNlgUbk6TJXVZvasuI9dYXC1aD uNVOYw+uhIByz3yvoJvX8kLsKebXS84= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=RjT1djYl; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712271661; a=rsa-sha256; cv=none; b=w+A5hHylH8nl+RpkHjs2cSI1U3JckTmiapGVUkIcaOOVjAGI5d3p1+BlSA42dZHXOjUWeK 0o8rFxvFlnZq+r8rkj4sfHuRHr/EMiWb14eDTmtWsaZ3Ns5QxDzaB+9SMaJCpyqsQ69vhP 6Vsm5s1HlMAo+IGK8HjutLdRmEPLj6Q= Date: Thu, 4 Apr 2024 19:00:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712271659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KHLNB8rkpoKwDhM7NRf7iWUfLDgvBLjzklimu7mkdKs=; b=RjT1djYlTZqBwHogqp4zy40F3SqAdaK+3oWOfGDaM6L3NSOO4dCastLQfuNaOlT1Dgo7Wv i9k29lxad1FbeHT3aK6BLtfd8jnI/QWfQOgpcP7kCCmnpZ6YfJaUcPMAV7nzKK1Ptjb3Iu +YlbAoFGlEHtL49GVJGZLcl1jqHQD6A= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Andrew Morton Cc: Matthew Wilcox , Suren Baghdasaryan , joro@8bytes.org, will@kernel.org, trond.myklebust@hammerspace.com, anna@kernel.org, arnd@arndb.de, herbert@gondor.apana.org.au, davem@davemloft.net, jikos@kernel.org, benjamin.tissoires@redhat.com, tytso@mit.edu, jack@suse.com, dennis@kernel.org, tj@kernel.org, cl@linux.com, jakub@cloudflare.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev, linux-arch@vger.kernel.org, linux-crypto@vger.kernel.org, bpf@vger.kernel.org, linux-input@vger.kernel.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH 1/1] mm: change inlined allocation helpers to account at the call site Message-ID: References: <20240404165404.3805498-1-surenb@google.com> <20240404154150.c25ba3a0b98023c8c1eff3a4@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240404154150.c25ba3a0b98023c8c1eff3a4@linux-foundation.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 97AB040008 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: d7cwza4edhd9kskjc7mny4eipguyn83g X-HE-Tag: 1712271661-939616 X-HE-Meta: U2FsdGVkX1+eKndKc/Q8dyGd5z0IAHXth2ysYz16N245tRKWVoMf5Bw6yMFhQPe/AgvwRZcEzcKY6cqq0ea0uw30O/TvfyMexRU2hjIsOnnLH/vLr6F8S+vMxxmptf9wJlIv5kkcLdxxnB3Wwpz2N/H/7L1ixRCTgT4RrXTkAKWQ6zJPYwFRS2GD1vMs5mK4shNISMDZiPw0k6dV3GvQaXZ9tvCdLI+hez88Kth3T8EJr4Y5Asf87F2JOVzZlQ8RHCBqZo1+yR+TvkGwD4CcBxd3Sd399EEQG2qIcBmX/YjTIrT7d2LLUO8/xq+oBHQq3C47vJlrgHeN929QbhKx88Ih/707vlKh3NazGe42c1YA9FXzN0cLc89tq92GBaVEQyCPB4E2ihJTgOqUGqDeGIthrVNdjAMpQ/2K71034OftMsCJoXqaA+R+bLdwZhRpXUfzN5xQtMTuxfHbttX/HKMGTLQb+zoxHF+nGWxb/G15xm0/1/OE26Jqi5pj7ZzfheTk9fjtg3y9rQy+hsSMEoaqUAb4y844iUL4+ejDjp3ThK7hXloLPyiZHvdI7u5sS8GgnYNbA1ltJSQD1QJKczf89Hh2fIYNg86U+iM1MALzvgf7yth+QsDb4Zu0VPa6OAhM9hbxc8vxSEINue9L2wfIwjZk6C+ueJl8LlXiQ59h9LI9xyCJz/ymBbqr5ZC0JlwQUs28vRD5gjnqgWe+CTqNtZGfwGic8qRzVFMlnQafQ/lJ5rkGxkAOny+cIj8xI1QBQwHw9Hx33MbnL9tCK7ODyL6d5JkrMLqEiXJPBP8= 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 Thu, Apr 04, 2024 at 03:41:50PM -0700, Andrew Morton wrote: > On Thu, 4 Apr 2024 18:38:39 -0400 Kent Overstreet wrote: > > > On Thu, Apr 04, 2024 at 11:33:22PM +0100, Matthew Wilcox wrote: > > > On Thu, Apr 04, 2024 at 03:17:43PM -0700, Suren Baghdasaryan wrote: > > > > Ironically, checkpatch generates warnings for these type casts: > > > > > > > > WARNING: unnecessary cast may hide bugs, see > > > > http://c-faq.com/malloc/mallocnocast.html > > > > #425: FILE: include/linux/dma-fence-chain.h:90: > > > > + ((struct dma_fence_chain *)kmalloc(sizeof(struct dma_fence_chain), > > > > GFP_KERNEL)) > > > > > > > > I guess I can safely ignore them in this case (since we cast to the > > > > expected type)? > > > > > > I find ignoring checkpatch to be a solid move 99% of the time. > > > > > > I really don't like the codetags. This is so much churn, and it could > > > all be avoided by just passing in _RET_IP_ or _THIS_IP_ depending on > > > whether we wanted to profile this function or its caller. vmalloc > > > has done it this way since 2008 (OK, using __builtin_return_address()) > > > and lockdep has used _THIS_IP_ / _RET_IP_ since 2006. > > > > Except you can't. We've been over this; using that approach for tracing > > is one thing, using it for actual accounting isn't workable. > > I missed that. There have been many emails. Please remind us of the > reasoning here. I think it's on the other people claiming 'oh this would be so easy if you just do it this other way' to put up some code - or at least more than hot takes. But, since you asked - one of the main goals of this patchset was to be fast enough to run in production, and if you do it by return address then you've added at minimum a hash table lookup to every allocate and free; if you do that, running it in production is completely out of the question. Besides that - the issues with annotating and tracking the correct callsite really don't go away, they just shift around a bit. It's true that the return address approach would be easier initially, but that's not all we're concerned with; we're concerned with making sure allocations get accounted to the _correct_ callsite so that we're giving numbers that you can trust, and by making things less explicit you make that harder. Additionally: the alloc_hooks() macro is for more than this. It's also for more usable fault injection - remember every thread we have where people are begging for every allocation to be __GFP_NOFAIL - "oh, error paths are hard to test, let's just get rid of them" - never mind that actually do have to have error paths - but _per callsite_ selectable fault injection will actually make it practical to test memory error paths. And Kees working on stuff that'll make use of the alloc_hooks() macro for segregating kmem_caches. This is all stuff that I've explained before; let's please dial back on the whining - or I'll just bookmark this for next time...