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 AA4B8C4829A for ; Tue, 13 Feb 2024 22:29:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38C7C6B0085; Tue, 13 Feb 2024 17:29:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 315C36B009C; Tue, 13 Feb 2024 17:29:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18F346B009D; Tue, 13 Feb 2024 17:29:22 -0500 (EST) 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 006826B0085 for ; Tue, 13 Feb 2024 17:29:21 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C228C407E9 for ; Tue, 13 Feb 2024 22:29:21 +0000 (UTC) X-FDA: 81788222922.30.0865F3C Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf03.hostedemail.com (Postfix) with ESMTP id B352F20016 for ; Tue, 13 Feb 2024 22:29:19 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NkR1gNLT; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 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=1707863360; 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=wx/MC+bC4jjIx0YLEQfGF9XmXIKmKElg0ARBnR+PN7U=; b=vUpgID2jMZY6lBgfAdx2lRsmyB46cUuFmuMq4Wm+z1jMkuyYKNm5cHeD8OOPIn1bnAO8Dv M3n4FHl2yM52quN0vDXCi2A1Ovbim9gfruTZUjWXystIFszKEcfRPRDTxtmtBoYcFNSbEh G7Nijd8SOXGK4sWufxK+/oSYVISgOG8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707863360; a=rsa-sha256; cv=none; b=lMNSWelqMB4REhxLBbr+dnD73DaaYnqJ6q5fJk3E4lWFV34KJMPxNfy6aGh3mZ0RmQoM/i /Fh79GaJpt3PQEXivE1Tq9NooA/oK4x0mM+GDTVt73lBJXUCUo3Ggz7QGnEctOq9gSF/5u nZz8H1WHOP4FS9X3uZRcY+8MjaS48ug= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NkR1gNLT; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 13 Feb 2024 17:29:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707863355; 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=wx/MC+bC4jjIx0YLEQfGF9XmXIKmKElg0ARBnR+PN7U=; b=NkR1gNLT+RslhaXlT2mq+xaYEQdluCzm3dX/A6JCoEiHuJfxIoq5giPdBQiazQrbxW3d3H NAWI1FOS39F6bwgQHKcV40dBRXc+mP8riyFuX3w+XvU40iyQ62zvPPtotTap95Rpir3zAT qPzlJdKC0PPafov0tierh8SpKFGEJjc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: David Hildenbrand Cc: Suren Baghdasaryan , Michal Hocko , 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, 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, 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, vvvvvv@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 v3 00/35] Memory allocation profiling Message-ID: References: <20240212213922.783301-1-surenb@google.com> <9e14adec-2842-458d-8a58-af6a2d18d823@redhat.com> <2hphuyx2dnqsj3hnzyifp5yqn2hpgfjuhfu635dzgofr5mst27@4a5dixtcuxyi> <6a0f5d8b-9c67-43f6-b25e-2240171265be@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6a0f5d8b-9c67-43f6-b25e-2240171265be@redhat.com> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: uttcxg9j4qcxc6zgqp388unc4mw8r943 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B352F20016 X-Rspam-User: X-HE-Tag: 1707863359-169007 X-HE-Meta: U2FsdGVkX1+/FMPEvllDScI/0BiZx48QeGrm9n9gWe//NMMuue1sKGxLgfsI0I4L33c0xA7rd1haIXoWUnpKxiHzrsp/0g4stkZLdQUHq5g6PZ4WP+kuXisgMaom5r8dP/2rzmrZPPIPiK9cLekSK8KgaWR1H26nnx328jRxQkVCLFJAgb7fJphVQVRazlLO8vEXzF0F4PSKxGEwy6exPtdd5x6ce/ZQdR7q583JwKOWGBbZ+C/EjiVkJuA1JciRI5jYkl2YuEFF/3nGKXT5gCNF3cQbw25XIpD+UqEhDit6vp88B5u0TrCJ8iVCjnitGBPozhzXU9ypCddXGRPRa8NqjAvK5aOaobXi6PRXZl+D/kpo0W4rYSpXqJfPIp8R43QEYvs1rm8Tt/mKJA7C5/LnwyziN8SZw7TsMG0HfTe+bGzkJiU2D9JJdfmhsmFbIT4HrWJti9x/Ie/TlI1+RCTrm1Os8wz2p+bbSeT9p+DmeU1RogtbyFYHoAjhKM/ZH5fF42x59Fm/ww8+gd5QTJOVGD5OM1frBk0feqYd4SNIcuRVHm3XDsnMpvdN5FJ7M1LReKVxd7O5IYsn1hunHQXnIqLWhsWgATVd8CRaINYizMhjVCsxpfP5fYNIHUfLowGHKAwAgVuEXvyHe2DCNUA8d6oeMzvyfoC6MRHaKkC8JzR3p1MrOfRlygxgF2CtX577KzpBXtoBFILKiBpTqolVRNxGVzXky8OcqI0SLzw1J9wWwtYiIQiZlVv7LIENBzZC2kcqHELOWrTT2/O0CobRLXzjFn3i9Vo7SjfgKA0lqTegWTbs8Q10iBBir4guBDlyHLrLEhF6h69k4LmpmtOqWyv5QQeuFbHDygyTYQ9r5CdhWFxEIGJDFHRLiAaJi2U7Zm7KKuZNAe8dSZtkoCqo6ScYvHVv6vcoVYhdM2Jnl6kLThljmUycp4X0WWuZPgAp8fova8aXFB/CiEL Tl2iuaSB 944O7qwiJvMy/iHprxf6yFBOyWx+IfpsY4DfNF7VnjUnWYP2ti2Sz1YltAgCuzIFhGUD+qoPlgl8TwX7GFqJCpdVANmm1hWiPdSrrqo12zslyAxZf71V8gAerVxcXJd6pPe9AB4wFFYv/e+0CqGtsw1XIR9Nmyh1yhMLLl42GKq7nLkq2ovv42E62ADJ5E4l3lstSxgfF6p0KJDe9TWLaK0TpUg== 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 Tue, Feb 13, 2024 at 11:17:32PM +0100, David Hildenbrand wrote: > On 13.02.24 23:09, Kent Overstreet wrote: > > On Tue, Feb 13, 2024 at 11:04:58PM +0100, David Hildenbrand wrote: > > > On 13.02.24 22:58, Suren Baghdasaryan wrote: > > > > On Tue, Feb 13, 2024 at 4:24 AM Michal Hocko wrote: > > > > > > > > > > On Mon 12-02-24 13:38:46, Suren Baghdasaryan wrote: > > > > > [...] > > > > > > We're aiming to get this in the next merge window, for 6.9. The feedback > > > > > > we've gotten has been that even out of tree this patchset has already > > > > > > been useful, and there's a significant amount of other work gated on the > > > > > > code tagging functionality included in this patchset [2]. > > > > > > > > > > I suspect it will not come as a surprise that I really dislike the > > > > > implementation proposed here. I will not repeat my arguments, I have > > > > > done so on several occasions already. > > > > > > > > > > Anyway, I didn't go as far as to nak it even though I _strongly_ believe > > > > > this debugging feature will add a maintenance overhead for a very long > > > > > time. I can live with all the downsides of the proposed implementation > > > > > _as long as_ there is a wider agreement from the MM community as this is > > > > > where the maintenance cost will be payed. So far I have not seen (m)any > > > > > acks by MM developers so aiming into the next merge window is more than > > > > > little rushed. > > > > > > > > We tried other previously proposed approaches and all have their > > > > downsides without making maintenance much easier. Your position is > > > > understandable and I think it's fair. Let's see if others see more > > > > benefit than cost here. > > > > > > Would it make sense to discuss that at LSF/MM once again, especially > > > covering why proposed alternatives did not work out? LSF/MM is not "too far" > > > away (May). > > > > > > I recall that the last LSF/MM session on this topic was a bit unfortunate > > > (IMHO not as productive as it could have been). Maybe we can finally reach a > > > consensus on this. > > > > I'd rather not delay for more bikeshedding. Before agreeing to LSF I'd > > need to see a serious proposl - what we had at the last LSF was people > > jumping in with half baked alternative proposals that very much hadn't > > been thought through, and I see no need to repeat that. > > > > Like I mentioned, there's other work gated on this patchset; if people > > want to hold this up for more discussion they better be putting forth > > something to discuss. > > I'm thinking of ways on how to achieve Michal's request: "as long as there > is a wider agreement from the MM community". If we can achieve that without > LSF, great! (a bi-weekly MM meeting might also be an option) A meeting wouldn't be out of the question, _if_ there is an agenda, but: What's that coffeee mug say? I just survived another meeting that could've been an email? What exactly is the outcome we're looking for? Is there info that people are looking for? I think we summed things up pretty well in the cover letter; if there are specifics that people want to discuss, that's why we emailed the series out. There's people in this thread who've used this patchset in production and diagnosed real issues (gigabytes of memory gone missing, I heard the other day); I'm personally looking for them to chime in on this thread (Johannes, Pasha). If it's just grumbling about "maintenance overhead" we need to get past - well, people are going to have to accept that we can't deliver features without writing code, and I'm confident that the hooking in particular is about as clean as it's going to get, _regardless_ of toolchain support; and moreover it addresses what's been historically a pretty gaping hole in our ability to profile and understand the code we write.