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 56590C77B7D for ; Sun, 7 May 2023 21:53:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 843F66B0078; Sun, 7 May 2023 17:53:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F4456B007D; Sun, 7 May 2023 17:53:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 694DB6B007E; Sun, 7 May 2023 17:53:27 -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 5645B6B0078 for ; Sun, 7 May 2023 17:53:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2D205120B01 for ; Sun, 7 May 2023 21:53:27 +0000 (UTC) X-FDA: 80764810854.08.6A3075B Received: from out-36.mta1.migadu.com (out-36.mta1.migadu.com [95.215.58.36]) by imf21.hostedemail.com (Postfix) with ESMTP id 2D7A91C0005 for ; Sun, 7 May 2023 21:53:23 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aZwHReiw; spf=pass (imf21.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.36 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683496404; a=rsa-sha256; cv=none; b=KZPgwRZOURuYPCpm5l/a9VxHFiBSt5FjlOdhiYPfMTAA3J95C/x1kT/MG8UgssiG426905 R0uSyjLEkrMX9qyVys8EppkIgWzcp7zenuNbZXTtrRjc0cpTTVWynU0lU5u2Y19TZ/mi/+ Tx7p06whTVXL7zxvZ8cde+WzY/wdsyo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aZwHReiw; spf=pass (imf21.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.36 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683496404; 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=40BqnBW4/FlB5TIf35hpUldm+3Y4zBbG09TnotWsOUQ=; b=tO3pcWKRCjPcqmhAeNPhCyIu+pl2LMvFrZFCqeR3HbC7PQMTYUABuCev8DHvZuXL14FBQg 20eZrPwATsi9+FmqiGOxdrZFArKjDh2qqDuS1hTsRoH7TcWeKn9kXhFR7q4IgKP9eITKvt pyaK9q1W3SlcrmorZq0mpsSKcglO7rk= Date: Sun, 7 May 2023 17:53:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683496401; 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=40BqnBW4/FlB5TIf35hpUldm+3Y4zBbG09TnotWsOUQ=; b=aZwHReiwGz+3e0UjAyYj3995zZnryJ+HL6chp+zp8zgo+84Zzb4sqI84KkA0FnHWWjB0Ry O/PRLGaSRAAHgRRCQkiBNiDE0ElsoXrkNmCxIUn8Xi9jG500CuG6laUuF0IdWR/J+txpy4 npcSMQCrutw4mV1bOYsx8fosQG6rKzs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Steven Rostedt 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, 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> <20230507165538.3c8331be@rorschach.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230507165538.3c8331be@rorschach.local.home> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: 8t9xdrgmbbwbmnwob6k3hokq91s1isa9 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2D7A91C0005 X-HE-Tag: 1683496403-205745 X-HE-Meta: U2FsdGVkX191+JM4aVdBO5UALugRZ0Y2+p7VoSSXqUFU3SS28J2fl9CV6TFneXez3G2vucJNBan64S+c57r3s5w7gAU04kTDXBhv0Ga1r5M0LY7LHr19ywsu1INuAsc0VePgW4vd5ASuDAoP+fi5JN6BkIYvFnwdErSsBqziaK0jP0rlVGHHyx3baRKz9vHY5n+KIjLBVNQheRs6y8w7RpkbgovWo9lUjL0DSjuNVpS67DLgc0mB4Wi9zeC4dyjuGlQ70TMqIqUG4ukoLQV+dtPJPl5zay1dwnQ8NMGiQ2g+4CVRW4bopoRfYz5Id2+qsYHgdGB0+d3Y6caPdEecfrlUyaVlHbHwriFnMur1ua6U7pu5lDu7UXkE0RBvoxlJFQCqV9BaiNOqOPHBRB4UnnE9iDyZMu5b4B6xvWxUV+y/LazrTuK/Z0D9qYG39Lb00Z3yEgucLIpwL9htqwDnZmsCO2d7rlJPlCnf2KnbqcImmGFeyD5nq7DQsOq9fj5YqxN2ZhGh1VnQ/uTjBwi/UIzoY0ttMy3P8fUYOhQvG+JWwtMltGxVlrx9hR8zk4vMIvL3AkrkA8EzTe72cnmWelM1a9MSnJfAsg0bXvT2IFPKbAMmlf2L6FrTJz+CnYsW0AH8AVIc0glAhAbkNNmvikE5pXoXodfq7zkxmxi77hLCEoLND4rqCd1V+RH06E9VkZe/3jqJRnwn0B4dlIg0rbNw5ygEDqSVIbEontuoNFrUSk5gtEingaxPy1/4inSXGSNldfgeJCp1j5fS6vMXoNWhBI6UFFJ3E/M1Kej//6hQSVGMD+UBtHgf2H6GR4RAMZc8JXqZ5/6d4IhnI88WAhv/D/RrHPFRtOlat06lONdHkdIRQNRQ2K4vzK6dNGLWwH14EWwMFJASGBkq1h0WWzMn9Uqe9Pl5GAyVFNGVCoQ2iWHwP+lEYCSwd09CdrCK87w7l5YTdfVXgNyEhLq EuvkQ1hg DRWBVNyQO2BtkqPkJm0n4IJ8Zw/NpDOlvj4nHUTy+ZIgwRC5qeb7OYN+5J4pe9R6pN2CiOChyfk374U7n4WExzeYrmAFsZy1OyhFTqvjONAB1tpTAOZUSbg+uIw== 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 Sun, May 07, 2023 at 04:55:38PM -0400, Steven Rostedt wrote: > > TL;DR - put up or shut up :) > > Your email would have been much better if you left the above line out. :-/ > Comments like the above do not go over well via text. Even if you add the ":)" I stand by that comment :) > Back to the comment about this being a burden. I just applied all the > patches and did a diff (much easier than to wade through 40 patches!) > > One thing we need to get rid of, and this isn't your fault but this > series is extending it, is the use of the damn underscores to > differentiate functions. This is one of the abominations of the early > Linux kernel code base. I admit, I'm guilty of this too. But today I > have learned and avoid it at all cost. Underscores are meaningless and > error prone, not to mention confusing to people coming onboard. Let's > use something that has some meaning. > > What's the difference between: > > _kmem_cache_alloc_node() and __kmem_cache_alloc_node()? > > And if every allocation function requires a double hook, that is a > maintenance burden. We do this for things like system calls, but > there's a strong rationale for that. The underscore is a legitimate complaint - I brought this up in development, not sure why it got lost. We'll do something better with a consistent suffix, perhaps kmem_cache_alloc_noacct(). > I'm guessing that Michal's concern is that he and other mm maintainers > will need to make sure any new allocation function has this double > call and is done properly. This isn't just new code that needs to be > maintained, it's something that needs to be understood when adding any > new interface to page allocations. Well, isn't that part of the problem then? We're _this far_ into the thread and still guessing on what Michal's "maintenance concerns" are? Regarding your specific concern: My main design consideration was making sure every allocation gets accounted somewhere; we don't want a memory allocation profiling system where it's possible for allocations to be silently not tracked! There's warnings in the core allocators if they see an allocation without an alloc tag, and in testing we chased down everything we found. So if anyone later creates a new memory allocation interface and forgets to hook it, they'll see the same warning - but perhaps we could improve the warning message so it says exactly what needs to be done (wrap the allocation in an alloc_hooks() call). > It's true that all new code has a maintenance burden, and unless the > maintainer feels the burden is worth their time, they have the right to > complain about it. Sure, but complaints should say what they're complaining about. Complaints so vague they could be levelled at any patchset don't do anything for the discussion.