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 C5DDCC48260 for ; Tue, 13 Feb 2024 23:09:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16D138D0012; Tue, 13 Feb 2024 18:09:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FF218D0001; Tue, 13 Feb 2024 18:09:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E88F48D0012; Tue, 13 Feb 2024 18:09:00 -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 CDF818D0001 for ; Tue, 13 Feb 2024 18:09:00 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8E7BFA0CC3 for ; Tue, 13 Feb 2024 23:09:00 +0000 (UTC) X-FDA: 81788322840.29.C83CF4B Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf13.hostedemail.com (Postfix) with ESMTP id 91C7B20005 for ; Tue, 13 Feb 2024 23:08:58 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fgDMRJQx; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707865739; 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=Mzqjn1+my5U+9pn6lTJcYt1NGpNIWi5Z/k5UXgeN0+U=; b=f9LcaYPyRP9NIYVJugfRVc1pKFynm0d9gHcwZrLVIRguEin/oy/Rcd/+TQfFm/sVJci6gJ fzUcjMpWaX2FImlCGxLbOKktXKRG8+k9XVONFgKIv2JVid3nfvVkO2xO8/6xO8TWUnLyNq fAvPLcE0sgfM0xiP9pZwejYjPM10JHw= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fgDMRJQx; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707865739; a=rsa-sha256; cv=none; b=AoAJ++JjzldlHT7YuFf8AM2OIwIMyp1qLCMrPgOSbdrhR8XFIx1oiT2UufKqwhR+ZZ9ORk 1iWkknqApunw5LityA74A3mG5oJPLJls9+O8FMAz57GVa1tg1MJzTBlzfQ56foOFLfYL4N MP4QfftHyMdJ0m+NvW9W8FRI85cc6pA= Date: Tue, 13 Feb 2024 18:08:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707865736; 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=Mzqjn1+my5U+9pn6lTJcYt1NGpNIWi5Z/k5UXgeN0+U=; b=fgDMRJQxyg5ZaQ70wbvauQeVygT0FUfeMQ0qsWNmo4yVngfupLaBrifbmmB+NDciVw113f tg8T47r7vMzyQ7sfjXo6vLQrPP7wW35nMBVJrJoXBgP/YacFTsuXiEfZo2MVbtwEd3WQkY dJ6BjWexLTLrv4mambztuLxFKiGSJdE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan 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 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: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: huhec18kicmkjwoehbrbmmnnhfdg8ygh X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 91C7B20005 X-HE-Tag: 1707865738-452390 X-HE-Meta: U2FsdGVkX18sVigQ6BVVAizSkpn07SbCHglYO1DjnXICg+9/FEwgSxTYKN0jLjRU4+VgElsYOgLatGzma856ISq2LQixxd1XTmP/OaottLcF7XfMkfmH1CnQY8M1k4wgNhyGBaytgTUy76onOiKr2fYRxK3i5IrunoBefTLFaQ1rF4vSgB0PqQJovv0aBMylx4al6fl+ecqRO5kMiOI0dlZ8mVk0aPvUa8At5Jetsgv6zXnKbYp0lnuMj/2YfReBCPLfNgaoumq+zRfch6UvFx2OI7OcNtEvCWFnnqUUnqmf9TBSuu+46LZneRk5YfQ417Jh/67GjSxverV6L8u7PtNSOY56Xhu6D8s9XX/YN0HOExByQq4Bbhj7m/QWvYC2a1bOSkwGMVXe73vJfdlhydz7uF8qnVGSD3WHLA+o6CdVgwDNtbWTbwOd9PGd3RArxZyFZ9VeWmwEn9IDz6Qk7U9FLgcBV7jGNBaqDe5tPlCUUvLlPXVCotoyapn7iOgJDW1szYat2u7wSuodUyaRDb18t5Thot4iE7XHHJRyKU/9LRJrpws23xrPKYoyrtgc+hO7C/rDe8WYpmTPl1Ny9dCG/0yMystm0NRT4OOjOFz5rIWuGRZcG76NMu6/uZ02vviuI+4sG7oAPaWFO8R2zBbKlw3IlRtVRAUQvIYcbG/A5iAVakciAyqa7S1rghbHA2OWbqEUhUB3FMjtC5C3TEsEQ2L3drMpbUM7XLjOgUGWOCDxYwqclqzgI5M4byzkoqUG2CFj8FFewXFUtTRc6aIM49YRv4K9owIoPWeRQTI895cHcHejUmhJH3urkTLfC4QT7n/YVJMQdaOs1kVAPfgb8R/YB9wipqozbIvVYtCAkU4y+zNeqVW4NBfxGWnyTbcbIzwDI6xl0LPPmpQMj7SwvCzU9g3lO++UuRL79g/6yj5mqnq4JE739lTMa6fTVLBVZS50mfKPKzYgIG4 v5uXh5LS u3Q867ykWiLrVKPa/FY1TZI80Lt60+W6+a/6aaHwAx8rY2Lv0xgHOhLl2n7roplTU0VxvBp89BPz6YlWzXxjbsSV8ntA6knMalZdU9+Ivi0evbr48Pf+x0ltGZL/ubC8psGtEVFu2nDVAebZE8Xj1gOzEOM2tctQaSdGi9FhqfxVSFO+EnM2LoAPZk2/l2GoH51rRFUuj2Q4zjcg= 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 02:59:11PM -0800, Suren Baghdasaryan wrote: > On Tue, Feb 13, 2024 at 2:50 PM 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 PM David Hildenbrand 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. Hang on, let's look at the actual code. This is what instrumenting an allocation function looks like: #define krealloc_array(...) alloc_hooks(krealloc_array_noprof(__VA_ARGS__)) IOW, we have to: - rename krealloc_array to krealloc_array_noprof - replace krealloc_array with a one wrapper macro call Is this really all we're getting worked up over? The renaming we need regardless, because the thing that makes this approach efficient enough to run in production is that we account at _one_ point in the callstack, we don't save entire backtraces. And thus we need to explicitly annotate which one that is; which means we need _noprof() versions of functions for when the accounting is done by an outer wraper (e.g. mempool). And, as I keep saying: that alloc_hooks() macro will also get us _per callsite fault injection points_, and we really need that because - if you guys have been paying attention to other threads - whenever moving more stuff to PF_MEMALLOC_* flags comes up (including adding PF_MEMALLOC_NORECLAIM), the issue of small allocations not failing and not being testable keeps coming up.