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 695ABC48BC1 for ; Wed, 14 Feb 2024 16:56:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3B448D0017; Wed, 14 Feb 2024 11:55:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CEB168D000E; Wed, 14 Feb 2024 11:55:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB1C28D0017; Wed, 14 Feb 2024 11:55:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A81CC8D000E for ; Wed, 14 Feb 2024 11:55:59 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 501021C12B7 for ; Wed, 14 Feb 2024 16:55:59 +0000 (UTC) X-FDA: 81791011638.28.77E9F37 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf01.hostedemail.com (Postfix) with ESMTP id D3F6640016 for ; Wed, 14 Feb 2024 16:55:56 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=aP6eNqCb; dmarc=none; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707929757; a=rsa-sha256; cv=none; b=q8nruTsPaEdDi5HZWjPEWhhXjSjzcvfSNTFiEqwXYSF1YJ49E0Z46WY1YHfSd1xa8nmaWf JErED2o4pgX9f13Pcfk3l1aqOJFlfunGbIx+LVwxJUj1YOdhVmrTeysXJ7J0bR9YgPlfNi K4p2EP6wFyYmn/c4+14coLiKqDGcaVg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=aP6eNqCb; dmarc=none; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707929757; 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=tiTYbjQqGLnM5HLaU1m7I4ZW+k7FNgBvatNZAZim8+Q=; b=IjnMbaUGKopVLUoPiyHfyQHPau1oPMu71dSQzw5n2pHMTCPwC1sK/W1YilLtEpTtEImGCm +3F8QYh9c2CM4LffmzcP2+oS0G7EIv1QJPbefTHl3u6Dx1bnTnzCL2C/GHbOnHf2YmyuBc Dxv+2NSo7mW1hXnRcr9PTfGpPb+cpcw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5B907CE230D; Wed, 14 Feb 2024 16:55:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57F71C433C7; Wed, 14 Feb 2024 16:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1707929751; bh=Z1j0awbyiMqQJioymUvLXxMTBT0EGAz3kMP8dpbtft4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aP6eNqCb/UgW05i+ulED3dJ38CFlbF46c9ImepcRNWw3cqV444ebJY3dOVwDX0TpF Zry6nkCkfDuDtI3bkVsahvhtqzq0e6p7PwaST0Yzxnx6S2AOkZW5cKbC+D8uj2KfhL cXIdI5wkzTTOR16ASzaWYyPLnnwcg8bFmbhrKB3U= Date: Wed, 14 Feb 2024 08:55:48 -0800 From: Andrew Morton To: Suren Baghdasaryan Cc: Kent Overstreet , David Hildenbrand , Michal Hocko , 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: <20240214085548.d3608627739269459480d86e@linux-foundation.org> In-Reply-To: References: <20240212213922.783301-1-surenb@google.com> <9e14adec-2842-458d-8a58-af6a2d18d823@redhat.com> <2hphuyx2dnqsj3hnzyifp5yqn2hpgfjuhfu635dzgofr5mst27@4a5dixtcuxyi> <6a0f5d8b-9c67-43f6-b25e-2240171265be@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D3F6640016 X-Stat-Signature: 6w7x6rabwep485bfutcy81dkh95y6mbs X-HE-Tag: 1707929756-322019 X-HE-Meta: U2FsdGVkX1/aM0kTvdZaziKvlQe/UuKkiUm/z4kAtniiDSQaUcOkgh+WbS2iUPRwyNH9olAirdOqjAJ+BNT0wy5tNwMrBPdAJWU5eL5i1DEAgW4NHQsPmBgOXrd4Kdxv4Nrbek3TE/d/5DP3U0F1p7zqPSlNgPsVkNTXGmG+nyOUfgAWSomvIE3MWdP5l5xwEsPcx+/bNZZcuCFaIse6ZMMx95m93Evig2H37BPM2p4SQmwYiEBbDwjtcv5RWes9NC2g3yNUGBLEEDjwU6LewJopb1jxiyJqnqSrw8LBAmI9HrVVFntbTCFEpUwcEFb6+mvgz+wL8bfWi9XTPPL2SgnWFjp+e3CqT5XrH7NRjD/jrzij1mCudtf/WWTPdouKbqx0D0fVnthfbq7fo2N+/OkTUCPxSm0wadiebxnovPOuGFAA4Gw870LeJTXmJepr27AMOsw8GFOoliOe8nGF77x3UPAJPI58U9YTJ0BlpuSM0DwfY80s49SIfJteJ8h6Qj2vc35gW06ppOPcB0V904JRLqiZsAVyNkALELsosmC5aGXGutXj/zqvo1CTLRJoCpMJBQNR7ECwTRVAdILCxJg6dclD0EI7C9AHJkzndDeU5xh3TMN9svKYMLu6D1FJbEuUg2fJfJLJ9m36LH5gKCyfxYks5XWGlCTILM7JQNpXoCL+QbKnR4B0wJ2ZKA+U5xm2CohEXXBATdUy1gtU3pFihyZ6Y0ICKh3/ApZ15jdae6Sb7Mcq2BCBXK0zZDMQRtn4gA/uOBKRFBp/FB0Kd6Q6EMGSDCXDA/Zg5IlaOkKpTF3cCN56DYAYVQ00o7N8PyayRElVeDc4uANnA4eCV1GicEjrnSXMK1pIq7Rr4+sqNHVba/OVIKFtaKxwvdUYb0zTewEzma+0Obl/7VP4CdcEaTudxqQQtitS5Z9bLXB6eskQdoZiS0gh5ZA7TfCI2053ZT3u7vPeEHu0+qi 1aRO1yqr N/gONZUAk3o8gkh7xAuhL39TSEsif0CmNk+E5/RdRxHwg9f5XxBZY5Vq92y2Qj9eAaoUyT0DY9ltyH7VfZgrL+Q+ireUlf0h/3110gQpeTNPKYIC5fIi9tWFLc3XWo/8xaH//ntVZLAYnj7b9A5+0RHz+zP9KBUUG4wfrigww1+XdmlLSCCfFciZvSlydQJJ/QPBp/RBYtesJoRknL9Ek9Qcor7UZ70w6tNg8o9QShu5ESeE3tE3aHwRpWgQbUblXzHJiyN2GnAJYTTyYsEiF5Xc2HY27Yu2Ts/HpZznrRKpdTX9rpXyrNBnmSVa5tSzJJZ1M 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, 13 Feb 2024 14:59:11 -0800 Suren Baghdasaryan wrote: > > > If you think you can easily achieve what Michal requested without all that, > > > 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. Can we please be told much more about this compiler feature? Description of what it is, what it does, how it will affect this kernel feature, etc. Who is developing it and when can we expect it to become available? Will we be able to migrate to it without back-compatibility concerns? (I think "you need quite recent gcc for memory profiling" is reasonable). Because: if the maintainability issues which Michel describes will be significantly addressed with the gcc support then we're kinda reviewing the wrong patchset. Yes, it may be a maintenance burden initially, but at some (yet to be revealed) time in the future, this will be addressed with the gcc support?