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 D3618C4829A for ; Tue, 13 Feb 2024 22:59:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F9856B00A0; Tue, 13 Feb 2024 17:59:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 57E4B6B00A1; Tue, 13 Feb 2024 17:59:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D1216B00A3; Tue, 13 Feb 2024 17:59:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 277086B00A0 for ; Tue, 13 Feb 2024 17:59:26 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F12C0160B83 for ; Tue, 13 Feb 2024 22:59:25 +0000 (UTC) X-FDA: 81788298690.12.0D37643 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf26.hostedemail.com (Postfix) with ESMTP id 15B89140003 for ; Tue, 13 Feb 2024 22:59:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ksaDnkA3; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 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=1707865164; 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=844WXX5yd15NBvKyBWDdzovUDDmAUcOrqOuOYCpCKD8=; b=jOLny4u/aEPUM8xQcnsb/7JWIEDxk3RV6Jrsiz/O1X8N66rmgEPJu1JBQfOAXo0HCxCh6/ 0FUVdksRoTvPF8gZ7qNwgz0UJalw+SARL7qxG1cu1k+yxDaS5vDs9lXwtBaU+DeKB4Hi0F IQza/Nnelwf/WpWr9xc8HIfhfky19UQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ksaDnkA3; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707865164; a=rsa-sha256; cv=none; b=qdCw/I7JX2pNLJaZ79HuMBGgUssjWNO475DDR2iDUuPhvHLXp7g+wSiKQF3vBZJbAWkvx/ wYw5v21yiO3I1zCZMwKqizGiuKcQfse6cd8Er8qAPok2G2o9WW3eLaZmj/7fEWFnCFMtHd IuSYPe/H/IsUFaPZuFM3c5SXvwYBNh4= Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-dc238cb1b17so4683672276.0 for ; Tue, 13 Feb 2024 14:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707865163; x=1708469963; 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=844WXX5yd15NBvKyBWDdzovUDDmAUcOrqOuOYCpCKD8=; b=ksaDnkA3uVR8zN7xSJ7T5y8FUIqs8V6JSybu/dhWK5XYSE8X8lbiZ3aSFdS3JnXVzB 8BMi4TYx/MPfxdLHISdVTnq2FPNIOaPSB7Ed1F5Y8Sb7IDvdBSPpp5Bq+hhniRpbdhV9 rezWSYla5/B05jUFLjVDPtMHiiJvCEnMR0S4GvgEECOEWd6quK2uVrRz/ibw9CWe+Yd0 GEzHuyE8HH+nNci5sMyluXi3wzP3ApjCYZGTp+XjLviL5kJi0hHGfqrjRHCPHtKBB0J4 1sUWZcf8IK9pd5RW6oHtS/8Q+8PSjtYwNqPNe/qjo+8pbRyQRsI9C2zed+msdcxN3CV3 9Caw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707865163; x=1708469963; 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=844WXX5yd15NBvKyBWDdzovUDDmAUcOrqOuOYCpCKD8=; b=c0HB6UFRBCtXWZ5PSeSgpxuUbHBtOG83amcrO7N5Z71Xt2/k5bIU69x4JDDP+U83O9 h9/scrt0O9bwMmV84IitsOUHdUuFueNQBMtp2OMSbw2HWxulvmr/1JpjN7Fg+/wxYpVQ +C9C0tgwGK5p7Potq5xIElYhSglALg2X5LkHW95sM6yDBXV/kvRqdWcslpaaV1O7VZ4t Qxzqn2maJ03cpTBUOiiqnfpcRKAtE7UE8a5WILPcBjBq3re7X+rQlMMA+WDXGk3sa6iE tARBWSP9fLEaKBXcYvtFEQVzyvfbqgndldZSBNOIg0aFlsKPOVK3nK1l7dw6zRSdm0tD t0sw== X-Forwarded-Encrypted: i=1; AJvYcCWnGJLdkeLC7qpUv8THMCx4KDkb7vus63gA/qUibD+GoQ2RY66S+aKtSzDAZkIq/3n2H25jrtV9BIB3EOTKJMtjfUs= X-Gm-Message-State: AOJu0YyR8ZkevMgGtPJjl+1SbntrU+x3L+3Ww9oNTtAs3WqRESRAWvGN KddnAAchLGr82jMam8N+mBbqNHwmR3+7je3w6wwYyT14bti0g7iynZGresaqAk8SKQy34+twa20 uAUiVWEaWd/Gfe3to6n2V++hQrLQeO40TlkRP X-Google-Smtp-Source: AGHT+IEsak8qaWENuvHfc4VIgP7AWv/5RJ7avJuNvMpPoMXa//p1aEVkERJbZdcyqEU4FQCBMSTUEaA/SBMrUpfRqEg= X-Received: by 2002:a25:8691:0:b0:dc6:1869:9919 with SMTP id z17-20020a258691000000b00dc618699919mr694753ybk.41.1707865162739; Tue, 13 Feb 2024 14:59:22 -0800 (PST) MIME-Version: 1.0 References: <20240212213922.783301-1-surenb@google.com> <9e14adec-2842-458d-8a58-af6a2d18d823@redhat.com> <2hphuyx2dnqsj3hnzyifp5yqn2hpgfjuhfu635dzgofr5mst27@4a5dixtcuxyi> <6a0f5d8b-9c67-43f6-b25e-2240171265be@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 13 Feb 2024 14:59:11 -0800 Message-ID: Subject: Re: [PATCH v3 00/35] Memory allocation profiling To: Kent Overstreet Cc: David Hildenbrand , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 15B89140003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: krxk8c469bakfsbid8cn5fn5y9zh75yk X-HE-Tag: 1707865163-607674 X-HE-Meta: U2FsdGVkX1/DTZxsmzyooin3jjph+zHBvJBQon4GoKG+gVmRX3nwnS6t1bWik0UfOUOZ6zuMrZ1si4UEr0ZLdviSxHyEqNZPmly33AyTWWaNguGKqgeYMmBlC8CijxG/IzlT+fn7L7V2T3KrTJ2Esx2dlQv8hcfuhezcQ/BvLOj81tTpJDiSWoGhyDGtIl37H7HRKaOWV5MJzBoIDHSqlJAGfdfmTJY4qPhixCx1qA8Gq/5QLLnFu29QAoZKkd5ksomQaZYhQVPHqPxOvIn7uNa6GHfCrPA3ehzTMbyU8NXYlZTaPIKAJbt7rxXVCkwUQd9d0oWJ1/iZvwR4bOuYkFmvR/j0Tc6hfbJ5N894WoUmaw+ZLfm7hKSAVB0dXGDKKDPF3Du7TG0tSOhSnrVwWg2gFTj3yWnIpEKUStZQfP6qAo4NeqvoKHBoTKqfUm4wQx/aneT1Cd/kNxWSp4xzh4J27f3F79bcSJwKqWADAowUhWrhcCxnrut1KTNl88q8Zfl66H2o6/izPQP6cmE5DAhTwqrEjaFQ18bNsspt57h3bCMAS9Mj84YJKS586rugUiclZJ9dT5px/adShV3kQaO9crfhzUP9GyfmRycVvULxiYspy7hJY0wF1f8kSgt0WsAy6J+uZLhVqPBPC5n0EMH40QeXwQ4zY70ODM8lu3vYtmlQz5qw+95+Y3YUAxrOX4KxL3Gf4ico4rYvH/GhQh3N6rcu3iQW5XKtsCocssGz0lbIrAeDn/3nOgrZQ453Uo/3yC4LXo1cQ1Ik2TZPeOlw6M3q5M4uyYrhIfUzFU3AqkQpFd6sMPccve/wiaq9YO6S6R6qbKGEDkNPV8YydDPIACINmf/3tBeTAjuvjw4WV2ES35SGGxUlznU1qlwv6NHZNUvj8Lw+D+QkGkhIESaexkSRQj4Othw2sVG1pNiuJ6UrRhysAkr+c7/XOdIxikAYL+F+q747ZrnfH1g Fd7RsD4s czPC6VaYUdxQotKFyNES8asSTmdd5wPl6xcqiVvLSUZlKHL4eKqNVtvG9xJAKgzFJ81y8J12Va6oFBAnxNuyyrGp3ZpjOP8NFsYzP58Lp+qYHZtigOuT/qvROtzhdbYIjDb4iryMLm7U9KmY9huDE8P9Eo+CYCcw+Xz7RcIdVFZ6rs4e5W8gZ2rD+iGMTVUQBn6Ot/hbbPLerJ4t7fqTVIyPgpcIqW5yywFDEnEanbCNYPT2s9BgAcIe3AA6vQt3oB292B/uV6aWVDbW8D73FjrG9ZBFCyedUvy36Fc6r76l78gOl0TfUagLQma9kfu3y/3BUk6YndVaIjm0agU8lcy42rTIa7+np4PrwUu47TrWGundEDXKLq+AoRFGk8KPYndeY 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 2:50=E2=80=AFPM Kent Overstreet wrote: > > On Tue, Feb 13, 2024 at 11:48:41PM +0100, David Hildenbrand wrote: > > On 13.02.24 23:30, Suren Baghdasaryan wrote: > > > On Tue, Feb 13, 2024 at 2:17=E2=80=AFPM 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=E2=80=AFAM 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 wo= rk gated on the > > > > > > > > > code tagging functionality included in this patchset [2]. > > > > > > > > > > > > > > > > I suspect it will not come as a surprise that I really disl= ike the > > > > > > > > implementation proposed here. I will not repeat my argument= s, I have > > > > > > > > done so on several occasions already. > > > > > > > > > > > > > > > > Anyway, I didn't go as far as to nak it even though I _stro= ngly_ believe > > > > > > > > this debugging feature will add a maintenance overhead for = a very long > > > > > > > > time. I can live with all the downsides of the proposed imp= lementation > > > > > > > > _as long as_ there is a wider agreement from the MM communi= ty 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 th= eir > > > > > > > downsides without making maintenance much easier. Your positi= on 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, espec= ially > > > > > > 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 u= nfortunate > > > > > > (IMHO not as productive as it could have been). Maybe we can fi= nally reach a > > > > > > consensus on this. > > > > > > > > > > I'd rather not delay for more bikeshedding. Before agreeing to LS= F I'd > > > > > need to see a serious proposl - what we had at the last LSF was p= eople > > > > > jumping in with half baked alternative proposals that very much h= adn't > > > > > been thought through, and I see no need to repeat that. > > > > > > > > > > Like I mentioned, there's other work gated on this patchset; if p= eople > > > > > want to hold this up for more discussion they better be putting f= orth > > > > > something to discuss. > > > > > > > > I'm thinking of ways on how to achieve Michal's request: "as long a= s > > > > there is a wider agreement from the MM community". If we can achiev= e > > > > that without LSF, great! (a bi-weekly MM meeting might also be an o= ption) > > > > > > There will be a maintenance burden even with the cleanest proposed > > > approach. > > > > Yes. > > > > > We worked hard to make the patchset as clean as possible and > > > if benefits still don't outweigh the maintenance cost then we should > > > probably stop trying. > > > > Indeed. > > > > > At LSF/MM I would rather discuss functonal > > > issues/requirements/improvements than alternative approaches to > > > instrument allocators. > > > I'm happy to arrange a separate meeting with MM folks if that would > > > help to progress on the cost/benefit decision. > > Note that I am only proposing ways forward. > > > > If you think you can easily achieve what Michal requested without all t= hat, > > good. > > He requested something? Yes, a cleaner instrumentation. Unfortunately the cleanest one is not possible until the compiler feature is developed and deployed. And it still would require changes to the headers, so don't think it's worth delaying the feature for years.