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 39A70C67861 for ; Fri, 5 Apr 2024 13:47:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3A726B0083; Fri, 5 Apr 2024 09:47:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C37D6B0085; Fri, 5 Apr 2024 09:47:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83CCB6B0087; Fri, 5 Apr 2024 09:47:34 -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 638326B0083 for ; Fri, 5 Apr 2024 09:47:34 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2846A1A119B for ; Fri, 5 Apr 2024 13:47:34 +0000 (UTC) X-FDA: 81975605628.21.9896C0A Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf01.hostedemail.com (Postfix) with ESMTP id 69BFF40014 for ; Fri, 5 Apr 2024 13:47:32 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lrgsWBrb; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 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=1712324852; 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=RDkodhxPHjCRcYuHL8QJdxmj/UyX4mSAQyu360+3BOI=; b=u8M8qwB+Pvkiavq+/ryEBTvOdUlbngBARNVNGxYZbPRfIpacrRrlBwlEk5K2PvM03ymg8z IfNnPBHp8NY7vq2LPqn+bvGcm4Axmm/2HcYmbwfl2JD5BhSR2C/+RrKcuEdgWSjiDMhhwu 07dY1TwpMIDRzCcYvzCBeyDHJtNDZq8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712324852; a=rsa-sha256; cv=none; b=OwA8X6COo2S4n2/X7kMQEW7P0S40ku2HVFgcH+Nn6byqQLD0g6ESLHfrX0q3t0GP9WxGQc 2Zwa62q3wN9jCB3yamf09WDLMpWV4z5sKXuGbaoYNyf59YF5PvppFkEhQoEZ7mhpKzm7nQ DUJrOjQIVHQNFqGchQ/4k5VZ6Oh7zew= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lrgsWBrb; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-617dfcf80aeso1559947b3.3 for ; Fri, 05 Apr 2024 06:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712324851; x=1712929651; 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=RDkodhxPHjCRcYuHL8QJdxmj/UyX4mSAQyu360+3BOI=; b=lrgsWBrb+iCFJfxKhHezfBpetdwUXFUEEBYmoJYCddIrzK1F3FgdBV7Gf+Hs8LBKcf RL8S1Bj79pRi609k/Aei0n3Ruw8wsa+YtfdgacyH2OCgyq/HgEjfRSSqEBEITum5oY9i ZlrnIMI7MkktKjnF+oYI6/ZJjasTCK+Kkdu1htjABlaxzd4cs7cVF5Bt5efRxkA4g+vt M6HwxHuYpn18vN1X+anDf9XW3q2vsf63WSwTziD6NWX+f+ibF6UDFiJDjha/b//Q3L9A mzf4n64MFEJqX2sYa0yfu6DANj/aveR4/jTl0xUd4mHS0HO03rcx4NjNcfet4ZUkIeSD XBTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712324851; x=1712929651; 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=RDkodhxPHjCRcYuHL8QJdxmj/UyX4mSAQyu360+3BOI=; b=ZUS4rFVbD+S0oTo3SFJAuwJCMXiO+zmNjs0CzFBKOJYR8Qsa+dh63t+hSPiu6BKuCZ KE73+cjzrAJ2QnLEN3YsLo4bSWkwOYDWveNaEVobG+8UlO8q/2twhWr1z94dizgsWUK3 grhDFEdGW84jObfVK5NeCnKtA2A0IY10UYiCZBWlWNH07DRV2BiTXvfFycmbIrkDLsTH 1aJKMd7hKbE5G8MFCN8TTJRyA0FNkapdkY88EUIQDOx0Inh6k5Wkk2MBM5sW7O24fmFT HszZ11u9jSDRACRZN2jEjYpTeLxS3p8oVXceecsalxiGE4Q7WidfJzn8htY8Fh7pjdBJ laDQ== X-Forwarded-Encrypted: i=1; AJvYcCUVU6tWSpWWTPwSNvAflKNZc76Fu7JI4dQ7Z2xGFD1cC9mMFAKPyAUGd2bCJ6Ap3gZpUtVXMDU85/1ErqG1uulGtqM= X-Gm-Message-State: AOJu0YyZKIM8Vtnqsfjuewo9AUwyzYAdltGFTu01C0sMHLaqq8HrBe43 ea/2jY2UrF8+TU51cXW+GcX8021SPXoft0Gzg1QfS2fCAm7zpgYTw33X+oteZHpibsQgkiVxv5n 3sR53Tu1o1vWLgRnUOc1qwWubS8CHqwMEv8Uc X-Google-Smtp-Source: AGHT+IETt+9jSDY6jbVQEtdOA/2Ue8S5T1KTCdTuvtcb7ogtZ6i7ZvA/55fNMoiVG+R35qGWCJRB01iqaNVA/qZfNAE= X-Received: by 2002:a25:e30e:0:b0:dd0:2076:4706 with SMTP id z14-20020a25e30e000000b00dd020764706mr1142654ybd.31.1712324850962; Fri, 05 Apr 2024 06:47:30 -0700 (PDT) MIME-Version: 1.0 References: <20240404165404.3805498-1-surenb@google.com> <20240404154150.c25ba3a0b98023c8c1eff3a4@linux-foundation.org> <20240405095327.ufsimeplwahh6mem@quack3> In-Reply-To: <20240405095327.ufsimeplwahh6mem@quack3> From: Suren Baghdasaryan Date: Fri, 5 Apr 2024 06:47:17 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: change inlined allocation helpers to account at the call site To: Jan Kara Cc: Kent Overstreet , 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-Stat-Signature: nrs6gcc15es1ntgx4gjiizxt91zsnoi9 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 69BFF40014 X-Rspam-User: X-HE-Tag: 1712324852-421055 X-HE-Meta: U2FsdGVkX180DH2bb5kfwWtVcG7liO2y/FQq4fpMcDSy0fZAX4/rA3FkXuS/+pZyMJqe9fr0AN4ZG96GROXg9Sfa5bPx/bdG3cvispQqFpWeG8izkUyTWwaiMAVxm4gDEHddfC/iJc7oW5OUFWnYfWTBDFtlHVJOWQpqVIGKEbbNsWAxU+oaj3N7rhneCpePe6NTZfyOvadDaqAZk3iwq2k2YGx6jglyP7Dj+ANq2pgODqprh3AOdz9FDfVp9JjsG9xGj67Ts4GihRxOa2xn1UikcfBSWLGvmqIB1np8Ny7mvYA2fw4Ayyk1hMZI+tSoOFut3DFtER/8XoHRN8fjX37eqVF9AL4BDntBaVVgeNLF6cQjcwRz4BWm1ulVkb5urtDJm1eeFerFcvYCZQuORrs15PnM/Y+NpJIwKs5n5iGba3qVWsoSAgQiQl0pH6BI5sPEyF1hRKxfeF7P5MvVjl+pV4ek0NRz7Jlx68YFqeFqEsmckPalMHhQJVDQGdC89DBFLSBM6HrRtO3rZhAlsh4n7/8fJUwOdbyTozdngvjtQWQ/pkVfnpufovoN7o6As1FTi/J38Jk8IBWCewMOyPl1y94AehWAVVAD0c+KCIlBHjJ3opYGlDCahWWl6bSgeewOQXPRg8XksyeJ7jCXQ32AwedsxewofHCe+Gdj8m7PCYgVt2xC20fme+scrywqw1dz/YujswmVv31geOLYFGRWMCLaN6WLNphHjpkfH+nOi7eWsjJs8dHiYZbKTC0z7Zd3b0WEdtCxz37x53hz5HRFHJBWC1HiV1kXb4SjiTmti7MKH8q5wsYP/cnqS8od/4mhcsz4lwnbg+0InxTOeQ5jC+dsjxbDClzLVXYGq6IwJyo9CwRs+z2xlf0GyabAsE5y+61cU7aw452uqOdIVuYoh5OTMYL97gczkDwtSa6jrcjsKtdaz+xrKmjq28qOiYOGHmoGm2Bq7zzZk/u RssoddEb F4TtV 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 2:53=E2=80=AFAM Jan Kara wrote: > > On Thu 04-04-24 16:16:15, Suren Baghdasaryan wrote: > > 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 wr= ote: > > > > > > > Ironically, checkpatch generates warnings for these type cast= s: > > > > > > > > > > > > > > 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 i= t could > > > > > > all be avoided by just passing in _RET_IP_ or _THIS_IP_ dependi= ng on > > > > > > whether we wanted to profile this function or its caller. vmal= loc > > > > > > has done it this way since 2008 (OK, using __builtin_return_add= ress()) > > > > > > and lockdep has used _THIS_IP_ / _RET_IP_ since 2006. > > > > > > > > > > Except you can't. We've been over this; using that approach for t= racing > > > > > is one thing, using it for actual accounting isn't workable. > > > > > > > > I missed that. There have been many emails. Please remind us of t= he > > > > reasoning here. > > > > > > I think it's on the other people claiming 'oh this would be so easy i= f > > > 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 an= d > > > free; if you do that, running it in production is completely out of t= he > > > 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 tru= e > > > 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 giv= ing > > > numbers that you can trust, and by making things less explicit you ma= ke > > > that harder. > > > > > > Additionally: the alloc_hooks() macro is for more than this. It's als= o > > > for more usable fault injection - remember every thread we have where > > > people are begging for every allocation to be __GFP_NOFAIL - "oh, err= or > > > 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. > > OK, fair enough. I guess I can live with the allocation macros in jbd2 if > type safety is preserved. But please provide a short summary of why we ne= ed > these macros (e.g. instead of RET_IP approach) in the changelog (or at > least a link to some email explaining this if the explanation would get t= oo > long). Because I was wondering about the same as Andrew (and yes, this is > because I wasn't really following the huge discussion last time). Ack. I'll write up the explanation or if there is a good one already in our previous discussion will add a link to it. Thanks! > > Honza > -- > Jan Kara > SUSE Labs, CR