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 6BBABCD1292 for ; Thu, 4 Apr 2024 23:16:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF80F6B009E; Thu, 4 Apr 2024 19:16:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA8A76B009F; Thu, 4 Apr 2024 19:16:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A48566B00A0; Thu, 4 Apr 2024 19:16:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 884B46B009E for ; Thu, 4 Apr 2024 19:16:31 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 00F60C0E54 for ; Thu, 4 Apr 2024 23:16:30 +0000 (UTC) X-FDA: 81973410582.09.AC9FADB Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf24.hostedemail.com (Postfix) with ESMTP id 36C1D180013 for ; Thu, 4 Apr 2024 23:16:29 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="zndCq/G2"; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712272589; a=rsa-sha256; cv=none; b=1VJCEmxNvjTUQQ4HHeY3oKyatCOZVxsThCve03h6ox8rLF6LoPfQgxLXjZHQoueoUEXZi2 q5SkMj2grCp+o+wIMl9RrwRfzBW3RCxNy7Qz44D8CQ4pzG7LYo6pze4kdB2khyOHQJZnQw fZVT/NwVjeUSMyveSJ82xHd6Ep5pBDs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="zndCq/G2"; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712272589; 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=px33Bjt2eInHJiP0NeuRgUTO3pjhGqqLrEOvRjM23DI=; b=C9E1GqGrqBRAxGaLmRk5JKHIsOVVUw1mOwjhwYcSu2Upn7eeE0gNWBfzSS/USQp+Gd9i/a iRNbGsYJIRA3WhMJZ2CxNTeq7+uVMJ+EZ0F488BWDWZfXuUBfEpW2+v5H76wLAw7ZekP/x pqLGTjnNHMnYwZUKKMm3nD3TRIQ6tes= Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-dcd7c526cc0so1638553276.1 for ; Thu, 04 Apr 2024 16:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712272588; x=1712877388; darn=kvack.org; 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=px33Bjt2eInHJiP0NeuRgUTO3pjhGqqLrEOvRjM23DI=; b=zndCq/G2HRIP23zIjl2aUzJmnMsxCkqjtHNmGSxTvmtsAq92FuSYeY+RlBcgDpnZE8 GM28cCnnzz5m6zLnJR355mha4G+IuCSemdVB+dPeHq5s1TP/iQQeu6ceXtcH77yxI0ri 9U1UPF7wGvpzrDfSmILBuPykseQvnhBfQkW1bsm7guIIil1CPh4dWr4xy9cGzc73yi3b HJX3nMGwK2nBlweHXlZkIGJGDruSU6fPQYVKaobe2yOlJr1vGvPP7QZQwYLKlOYgtDAC 7K+AhXEat9vlWqK4At/np2XDeKne3d56M/HU9b+y/TQ3bD9Pxr59/EXUxMetqXX2iU+c W2Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712272588; x=1712877388; 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=px33Bjt2eInHJiP0NeuRgUTO3pjhGqqLrEOvRjM23DI=; b=k+4soluK5OkoulpNjOdYkleprEx/fxeXBT54c/nDOXRt94y1tO/JP0IxHjT/T36C9R eaeYfh3vxW1A2YyDU+6DGdRWO6sHi4mzmtujKfTxKquSsVg6dTSOdfQE+v0N5Ds9FEDv muB4GuFij9tOgar557rGMzRds/eIZ9lANxveEQzIgqqO99RHKydO38HB/WSJg76Js5U1 0eLBNXEkLEoq2wrXqK2GemZ6umU7Vmp+cRCRyro0IQbsj5vBIWq2RzdLg3QR92CTmp9U g9s9nO6vdJy7cZ5JDjZ38hNzFXVOpSaIQ/F6hgXAgDWdgaxv2NOiko8mAe0ksfCVFECF t3VA== X-Forwarded-Encrypted: i=1; AJvYcCW0X7PXIZI/5hMxFKhH7eMk/eMwRLy7LgtYfJGRj2aULcLYthFYr8JN0/iQrfffMhe2gfwMgy0GWG/JdDj2DmWGob0= X-Gm-Message-State: AOJu0Yw2GGV2FMOZr3noC1IBNrxlug8RH9Q5eWyzG4OSXtpxi8TxgzC4 RpGIdoWUZbiKXFCMsT82ZgVzru3iVcH/STsmb5TkVoWyg+PNuKEYHRQg3KW2Y5og83/BwrMU6CD doJ/M68yXpR+J2cZ0Pd0gZV9nO6mIBPqgNfkg X-Google-Smtp-Source: AGHT+IFqOT0sdB5Mq8Em3ez8wUqwsDenflcnFBaGGydYTj8cPQz4oQR3/fK7VmQ9yLCyTSRCqikRdMTTYcQR8Kj+db8= X-Received: by 2002:a25:c7c6:0:b0:dcc:d5aa:af36 with SMTP id w189-20020a25c7c6000000b00dccd5aaaf36mr1095387ybe.44.1712272587959; Thu, 04 Apr 2024 16:16:27 -0700 (PDT) MIME-Version: 1.0 References: <20240404165404.3805498-1-surenb@google.com> <20240404154150.c25ba3a0b98023c8c1eff3a4@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 4 Apr 2024 16:16:15 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: change inlined allocation helpers to account at the call site To: Kent Overstreet Cc: Andrew Morton , Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 36C1D180013 X-Stat-Signature: f6jps3ugfn1h4ug9161sz9idzh81rwgj X-Rspam-User: X-HE-Tag: 1712272589-188459 X-HE-Meta: U2FsdGVkX1+dwH3z5Z+yGdCmx6NSIzS/eQtAwT8rNUEFvdg7pe688RH9zj369AfE+GjmsZomQHJyHTji7ycQbzgKdynz1HVEhAw2RDHC20EairCjTYUiqPkCk7t4b2iKj2e3nLZe4AR5mmIHdMVjMfyjVUYoGAswnX3J5YRl9IsQMd79FwtUhgP69CLbGZ9g8o+svZAk2pOmr4JUtffe0AWgyAvZNYtOkaYoBa+IcSmVAUYQHyNGoE925OoE9YppqfrT2CrYdiRRgsJ/ViR2PvnaVkdZe+Mh3rJNWllWCKXmEq7MRB7prfds7fjy1MgH+IMUMqn7ElBcX9EzGiQqsasYWoFfu6riFupzGv8YUyEU96Nc2pVZP8DL4TCeGew6gxstDMPFyOdg2XjWZPy9z3bCUNyVNdKT2OgjFDLgrpiB2x1fBhbhWmSSa8mOmGTwShKDcrlorSBreDY9t+EaCb0WExchc2FepBAnqyRwFSTXZ3bQh008NSMyzR1rcjODiaHWxPrykfomUFntOFd0YQeR6+vZq/0F50Fhi74Ta7X+xZabrzO5uLht9GrcsHmxK6DKKj4jSiwaRriI9ohNtSfedQYcWYDEJuHIU9R/AnfC9Mn+cJWPo29BuvgPCsPzVk7YyUOQauoLuNQh0RzX/oAhkp3YQXChHwee5YkNdNJ0fWmcmnj981EgctIhE7w/We6jjDuQz4TqJNouSLL5NKtXv83CGovOtXZKvVxRGL2cKqkhMXteOM7EZvwlTz3ALHPn5ZDZfcDH5NRvRrywmnk8QwjkKHZl+8VXLvhNPLklibyHYLOXERJBPGFlvhFnCVKKlyaItRmpdQDPGpjdNUQxLhXETWofUAQ2NAsSaBZqDyPlQ3Mc3F2cjCbZv58tx2ciK+ZZ175l5+gLfE0lE4Oh24scpdpqlzJFJpldVK9tX1ofJWgzXYJjSYeC5sRy0YbkHUDXDZRXEF3u3uy bUvf5wy4 TEH7KB0wYVlxIoBfdJgI5B2EXcK3xIZ2GpsMduykxAwdjuJpVps37yPYyWd5b1eaV+N7xwcGh9yNjoJVt/iyWR272L5EzuLjA9eQsdwejDItsFO8egAhH+dIGbP6gmLv1IPXsiJvS+A0/FfSRYwjf1mM32NStHxa7fB4Itq4/tppeL1eC8pF8zxQ2BCgR/ybYEvX8CuPNUqZfg0FVtarp0qSE3F4jrQi0rF0aKTSbzhlPoshqEilwxUQHbZA6Dg0Yt5+5rlFMDlOcOXIVvtyYUyB0CjvMjxsNWW9EIJr25bIlDrArQMas+OSBHA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 4, 2024 at 4:01=E2=80=AFPM Kent Overstreet wrote: > > 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_chai= n), > > > > > GFP_KERNEL)) > > > > > > > > > > I guess I can safely ignore them in this case (since we cast to t= he > > > > > 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 co= uld > > > > all be avoided by just passing in _RET_IP_ or _THIS_IP_ depending o= n > > > > 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 traci= ng > > > 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. Yeah, that pretty much summarizes it. Note that we don't have to make the conversions in this patch and accounting will still work but then all allocations from different callers will be accounted to the helper function and that's less useful than accounting at the call site. It's a sizable churn but the conversions are straight-forward and we do get accurate, performant and easy to use memory accounting. > > 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...