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 33803C67861 for ; Fri, 5 Apr 2024 13:53:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81DA16B0082; Fri, 5 Apr 2024 09:53:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CD626B0087; Fri, 5 Apr 2024 09:53:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 695E26B0088; Fri, 5 Apr 2024 09:53:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4BB686B0082 for ; Fri, 5 Apr 2024 09:53:23 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0F29DA11F2 for ; Fri, 5 Apr 2024 13:53:23 +0000 (UTC) X-FDA: 81975620286.16.E743CC5 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf20.hostedemail.com (Postfix) with ESMTP id 4927A1C0015 for ; Fri, 5 Apr 2024 13:53:21 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y+P3Icbu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712325201; 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=lAHdE5NFk++ufix28SzhuwWBAI0pKipkj98VJiYe3GU=; b=l9C32Z7zNe+r5yzOrwgcFapf0k10pcKJmFIZAcH8KOu71RZd+GwhuatzPa9igY48r8vyeZ nNJhvz4AqzNMX4Z0DU+8aLbu2LkydLWMPgrtRB/BjR4IHVwOQO13d+d7nup7STCaB393nO zOLHUHw8NUO9L3MBL3ScZQHu8VaR3B4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y+P3Icbu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712325201; a=rsa-sha256; cv=none; b=Kik7QGJh8D/i8lsQ7IZxxFob8wsGi++trVuGOmaYUdYG/9GM5JXIz/0NTez1/9GcuiB+WI rDd9iRCuVnEtgCKve7F9A7eWJzS+m3J2zID/n6O6pgN50VBbmQ+AhpG2J7eCV35ZQhzpVM 3LGOdjWrqO29TIyA4JBl/eEpiUIyTGI= Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-dcc80d6006aso2280285276.0 for ; Fri, 05 Apr 2024 06:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712325200; x=1712930000; 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=lAHdE5NFk++ufix28SzhuwWBAI0pKipkj98VJiYe3GU=; b=Y+P3IcbuP9Y5CS+EHeIGvFTP9+Tqvy5YR4PRmQU15F0wTjC7vTmboo7+jsSftzB3oC aW344VAnXtfjCyAT1etPIThpxe3NMkxxgp1atbUgRUkW2NEzzQ+9ndNjk66I7d3M3rHC 7S4pJRkuS2s4mJ6TEjadqcyPV4Z5q/HHGiO3Pq1pJOm7dgG4jxnPSGLUtMVrImamUuis LdUnhImgwwlXSDRWdD3Y/4eh7wCWuFkflxPYxuOSQaCv+GyJkMiOQ0VAQGTxS3g7uhkS 70SwlfAX4QqWqB3J/UII98sO0FWGlCYlBnepi0udMwNqmkuqY6aGqnSG/XHrAtpECH5k L/4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712325200; x=1712930000; 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=lAHdE5NFk++ufix28SzhuwWBAI0pKipkj98VJiYe3GU=; b=UPK1ni/OmNkym7rdCZUpydYj/yOu3ITJ355PSOCwBgX/pqCOtFxEtgPiKwRv2bBwIV Vro39DILvxILk//D+b4XNWekOaH86xHfm1SyrWFXd0aLdbcYY4wvG1HPrBiLHCrAxDkt Xysf2n9K8vWuOwvHIIN8vkQtiX1nimSkXqCi1tuzJuqP3qfWuKoxjVkbUhxlDuxcLne3 GwKzIpJ6eAPyT/+TsnPAX8XHMLSVlyzxemBMwsU4XzikEyVlnE2vHo7z1LCT7PvEGwsH zAclACsmS2dG8mMFDdirGsscafOSFPqXcoyZzgdK4Q5aY6re/JD0YpcBMRkDQiuOee7I NjDg== X-Forwarded-Encrypted: i=1; AJvYcCXAZe9RIkUatvDHu5f5QgsorbcelMX03yb1KQPHvH9zZprbj4kwq2GMJ+1b8P10jij7dgJjKL/izFg++rQmjzG8aIg= X-Gm-Message-State: AOJu0YzePUOE/3eTWkRUzPaBYyaJ3tvfISN+RgBLpxrJnTClkk58b1ot wdyk6H3YyR8JX5Ade9YGsD9BzOfxJ3awKb5l7UFGGiKaea0fQCZsrHWRPX5sThx5auRyEUqGUGJ pGo+SsTdQk2R9k3a92X/nvzEekC0mHymMyDmP X-Google-Smtp-Source: AGHT+IH/KRHN+9M5N1gYIB2bCPgMB25x0KPnvuKiHgvgSCGh43Ngn+0mkz51p67LhizDAcBL1UgazcYTNlxqGDPZP2o= X-Received: by 2002:a25:f454:0:b0:dcd:b624:3e55 with SMTP id p20-20020a25f454000000b00dcdb6243e55mr1115241ybe.54.1712325200128; Fri, 05 Apr 2024 06:53:20 -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: Fri, 5 Apr 2024 06:53:09 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: change inlined allocation helpers to account at the call site To: Matthew Wilcox Cc: Kent Overstreet , Andrew Morton , 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-Queue-Id: 4927A1C0015 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: fj43b6ahms68q3fo57gy44i3kb93fox4 X-HE-Tag: 1712325201-944155 X-HE-Meta: U2FsdGVkX182GJrSzgx0ge/taKMoQUM0wdhJnGInR4JqNoLEImOXM6acgwbmpuAf4dP+71K9QoFZMilwyQw3nwVJNXcpXKYmw/XFiQ2SsuMwFC7R6rOVnXGAxftYaQrVn16Ul07I8tNHCgkg3NKrDjmRRNEKm8ON3S7o4fdIu5xyEyz4qBI+sNVx79nq6yqlNy4yIKjDwLl3DvB0n9kBd7/TuJv8UGWPAe6DszQRs46Y7F7tONAH9daMevGr4QxHfixyJygvNCC69JN4voK+cQuwA00MkBtMnQqtz5zMXi0DXnopdtACXBs5Q7rCe3APKLcicoRo/AHRiLDSsgErPK07NwdWACTFA0KAs9uuIaJtgG1LHbT6w+wBjfZD8hKWK2a7Mvgcnus19Om+sNWdYymq1jOPncNNG7/rwrZUSyHPbMbmxOIveWMEi9VlTVeniUcuRUAXK2wIQFq42hNKimTrqVVcdoMWbPj1eb2qf+3E1Wm/Pvjuh6az5oVbWA0hkQx7MKeH5GHqqhCzwIShbRWMx00oJKLQ25zFNhbInJkEJ84KAPKz296bPOMPd1Gsk2ebNIWn/JcA6iz4Ry6DlsnR1BOvL7PCpdud2gQDYS7iDSHXyNyyGljp9/nDrVyViYgO8L3bw7DF6ubvbFcSzC9R1ct8VlCfQBCOyZrkU7GfmqQodYb8EAZgvGOyoiDjv2B2ojRup8ycRJD7hr9tOpX5oMBGFhO5fAo883RBkxLcBzyu/jAE+n5I49CsIJ0+zvyp4Jv+KZNIsSvALdyGXR/saVLVesYgJolwWEDmaIgqEyDz1nLK2X6lUqquE4vTeMUZldQNWqfjgUS567uE279wTqEoTGqB98zEyMT9CREWTkBJ0+QS36CFRnRH/OtFZXSq3F0rIpqDKBjSpp7TDzp2smzs/1jtb86oocACVKQ8fNIDYPomkXuIrqj6cKo25tKlPLTonYIguAfQCU+ FWO82y+2 62SSa1qE4JX9ib+cUVfnBoor0S8BGRLrWk+5Q6oWhYrdAnrK1MtTwEzUjMXMGDY+2QsW4B/saM61ejHGL6Tr+2CNf7p0HGiFArlmiEDB5lQvplhoOii+tbYXlhFmxeny4k7VvY5MLYsCg2RSu8iZX8nW9YgTaOa7Q8qCHtG39jA+tPaaYmhl5n9vq15Ef8uMGElXZ2IAOuyMqnC4/aDAHbf6tgcAyasVsSRc72Nwrc4BenOZRX3H1ZBRil33/uL39fMw35/HnVuGQ8doG68Ig4xSLxwoOY6wRhZmnliI/hY3U9RzoTLeiR8NV7h8r6u4y0gKoy88u0qu3yauhTkMZV9+KlpASFJ1lgMH9yakF50Wg8sqP0vzgmT6z+Q== 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 Fri, Apr 5, 2024 at 5:44=E2=80=AFAM Matthew Wilcox = wrote: > > On Thu, Apr 04, 2024 at 07:00:51PM -0400, 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 wrot= e: > > > > > > 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_ch= ain), > > > > > > 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. vmallo= c > > > > > has done it this way since 2008 (OK, using __builtin_return_addre= ss()) > > > > > and lockdep has used _THIS_IP_ / _RET_IP_ since 2006. > > > > > > > > Except you can't. We've been over this; using that approach for tra= cing > > > > 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. > > Well, /proc/vmallocinfo exists, and has existed since 2008, so this is > slightly more than a "hot take". > > > 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. > > And yet vmalloc doesn't do that. > > > 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 givin= g > > numbers that you can trust, and by making things less explicit you make > > that harder. > > I'm not convinced that _THIS_IP_ is less precise than a codetag. They > do essentially the same thing, except that codetags embed the source > location in the file while _THIS_IP_ requires a tool like faddr2line > to decode kernel_clone+0xc0/0x430 into a file + line number. > > > 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... > > Please stop mischaracterising serious thoughtful criticism as whining. > I don't understand what value codetags bring over using _THIS_IP_ and > _RET_IP_ and you need to explain that. The conceptual difference between codetag and _THIS_IP_/_RET_IP_ is that codetag injects counters at the call site, so you don't need to spend time finding the appropriate counter to operate on during allocation.