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 5B35CC77B75 for ; Wed, 3 May 2023 09:57:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA60C6B0074; Wed, 3 May 2023 05:57:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2F406B0078; Wed, 3 May 2023 05:57:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F6F06B007B; Wed, 3 May 2023 05:57:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from out-27.mta0.migadu.com (out-27.mta0.migadu.com [91.218.175.27]) by kanga.kvack.org (Postfix) with ESMTP id 7CA2F6B0074 for ; Wed, 3 May 2023 05:57:27 -0400 (EDT) Date: Wed, 3 May 2023 05:57:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683107846; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUxQsWcAayZPSDpvKJX6MVjvEYhxJEaesagDt8ESMoA=; b=HUCOH/N80slFi5vErQvwXmQRVJPgvs7X0vQd0axDTlMk/yD6uS8UUgewhyEcC5YpGdd9lD Nfp4W/DmTbgBenfdi4cDwJFHiY7ZMVbWxr9EavpMuZfK1GaSdppyvarZLa7ZfejwjalZfu dEG41/SPqlqOodTMCQ2OgtLp+yIUXFg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Petr =?utf-8?B?VGVzYcWZw61r?= Cc: Michal Hocko , Suren Baghdasaryan , akpm@linux-foundation.org, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH 00/40] Memory allocation profiling Message-ID: References: <20230501165450.15352-1-surenb@google.com> <20230503115051.30b8a97f@meshulam.tesarici.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230503115051.30b8a97f@meshulam.tesarici.cz> X-Migadu-Flow: FLOW_OUT 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: On Wed, May 03, 2023 at 11:50:51AM +0200, Petr Tesařík wrote: > If anyone ever wants to use this code tagging framework for something > else, they will also have to convert relevant functions to macros, > slowly changing the kernel to a minefield where local identifiers, > struct, union and enum tags, field names and labels must avoid name > conflict with a tagged function. For now, I have to remember that > alloc_pages is forbidden, but the list may grow. Also, since you're not actually a kernel contributor yet... It's not really good decorum to speculate in code review about things that can be answered by just reading the code. If you're going to comment, please do the necessary work to make sure you're saying something that makes sense.