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 BEABFC48BC4 for ; Sun, 18 Feb 2024 02:21:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14E086B008C; Sat, 17 Feb 2024 21:21:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FE1A6B0092; Sat, 17 Feb 2024 21:21:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE0B36B0093; Sat, 17 Feb 2024 21:21:35 -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 D9B6C6B008C for ; Sat, 17 Feb 2024 21:21:35 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 59C1C120376 for ; Sun, 18 Feb 2024 02:21:35 +0000 (UTC) X-FDA: 81803323350.29.E96817C Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 801DE4000A for ; Sun, 18 Feb 2024 02:21:33 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=38l4rsZO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 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=1708222893; 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=aGwMPlFmMn7i+PsCRsmYPKBrgHwqE0wRHG6PNy5zjw0=; b=wC2cQtmDeUnqHYlfNPUqut1UfbwGMlMK1AoBnmUlnu5MDKPWQGdePIHr1od1YwvSWQR5WZ P8eNxlI7lcCVFJGp8YQyFu1PgDUZuIqgujsfQSayDKDMeAAh4jgVPsyTByuOh/pCQw6qo4 C4W0XjaaeLfR3+Zt33sn/DKyEIhjhvM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=38l4rsZO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708222893; a=rsa-sha256; cv=none; b=J1ED9Aa5F5xlJBH4B+LmQ9nGjilkq7MNCBunEE/8thKhZAgi4CK3A16tku35DrNlz2zori ovDt2C52xfY6N1doxi0CWt7tERiXKQMCe35oPCsrmvI50pAasNkXlpAC4jyJ7i5MRdwYhI QdOcLk5zSH71gRR4+N4hG8c5nwIbQAY= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dc236729a2bso3041739276.0 for ; Sat, 17 Feb 2024 18:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708222892; x=1708827692; 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=aGwMPlFmMn7i+PsCRsmYPKBrgHwqE0wRHG6PNy5zjw0=; b=38l4rsZO0/mSsmxWj6gQTzuGrEuQ4EKj8+g2QsB/mFUMKFv7VrojuX8ULqGyu/hg7u cKDp05MhiBAtPeD6H55BKvGU7Ie1eHEu4KIYjs1U962nsZ97kYvmEHDcpDuab6weGmlM 042GcoPok8SB9aGasO2xp/zgQf6xlR4PuQBaVODT2iwh3rnlFRcggc9Km4ZI28CKpGb6 /2+cNL1O2I4OECfTxHbQsxPMbypnysXjlMYcSkPGrImPa1bVE8BUoPuW+nItXO1PokGF 4Xg5xvgokk4AU//qDFDH9ek7iiq+4u1FslwVWVlI4A2SPPhm4xuJUqkKIf38PmZwBorn 5mNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708222892; x=1708827692; 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=aGwMPlFmMn7i+PsCRsmYPKBrgHwqE0wRHG6PNy5zjw0=; b=qOUMfTSOEYUyx6anviyPduxdNRDx4hgU3MYhSmB/wSzUJ3Y2s6Rs2CaQREuWmpVWs3 3b0cUosKIQXl9nRl+lD0clataZsm7IQBjdwWVxdxubXDDgHwfWQWKECVuYd+O8jds+S4 ZwCvIWuND4HI5QHKpqDWJH7EV8+0tveZE1T1Qgy09bcPkEZybB+P005YMD/yUVJAnXBW a6ByXjHg7N7IQCEPfwYyQabDvQWeuJqpfB+IGQqDAssqmcJlH4EZBdOKXMbvyQ+zEm25 50dH6iFvYjKa/h8vb75joPCBgjuwfsjvXBZtTdxgzBUdmAt9MZaZzk+zt05Che8gGYDs P03A== X-Forwarded-Encrypted: i=1; AJvYcCUw8YeAhy2fK6fu/Dl9n+141EJJztSmLD24ZGR/vHmk7HE/wYIz6EIIFkdo0H57O3VGqyHojhBpfYI0+a4HTv4c3IE= X-Gm-Message-State: AOJu0Yx463ygQd559guZ61v75z1rYl/mYtooUT4AAKVoZqdR0VrLq2fF A5ZcJMdn0T7qAgEwT5c7zIF+BqlZQHxttCibOMQ5nVuLKEcvb3EMwJ7eNJFT8QBVbFnVRFUYaBw wZrgkJqQXPWGlUOukunQHQubgZSi5EqyMhkqc X-Google-Smtp-Source: AGHT+IFbcmWP0wuiiRTf0AlfSBMbSNfrD0N8TNtgVp/GNQHvOsL/OfZQsmBKdpZvPdO7G1/QjsP0VpRVVtpV4P/uhdk= X-Received: by 2002:a05:6902:268a:b0:dcd:4e54:9420 with SMTP id dx10-20020a056902268a00b00dcd4e549420mr9768527ybb.5.1708222891980; Sat, 17 Feb 2024 18:21:31 -0800 (PST) MIME-Version: 1.0 References: <20240212213922.783301-1-surenb@google.com> <20240212213922.783301-14-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Sun, 18 Feb 2024 02:21:18 +0000 Message-ID: Subject: Re: [PATCH v3 13/35] lib: add allocation tagging support for memory allocation profiling To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, 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, 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, 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-Server: rspam09 X-Rspamd-Queue-Id: 801DE4000A X-Stat-Signature: k6do184bu8gfi3buac959ordorcsk8ak X-Rspam-User: X-HE-Tag: 1708222893-957846 X-HE-Meta: U2FsdGVkX1+qkb4j8MiyeY5J8hw+DsjaYq3mjJYLkhsO4oZo7eX26sqpT+aEYX1UgBWRJUQsphcOFOdVbdgQ2elYF9RHPVeL5mOkc5i0gaE7q6r2HzE+OIGLNldgzlzPx9iz18N2s/yht9v3Dr/OrDkwFXGkIGlIcDfdwVsp7A3FAIQTrS1QXJFQr97z08e/1Jq+KvV81oqAjZTLQRckgxsR4ePOASam/CFg2bED/tc+vHxTJSjlg0uBgHYY09x18IlJJzu4duFSYuDe3XjDg3+v5Ew5+GLeDW8J4Tml4DlZX4+swpQVAmCYyj+SqffBIHk188PzD9FOzfAZK+vSkdYdWmks3rwN7y5GI9+FqVJQPoQjpQrZz97ZayhmPVij8rqI7tyaOvWCfHlBf/v+0p1vJPPodatt8lvTpASp6L02JcE+Me2mz++ngpDLw0D5G1C++7WZr9bhoCFmDvy8S30bDcPEOGIZy6ACjsKVoo/y0Dl9KjiCltyHlvW6u8iNdnTHMBImbrukJsU4N65pLj9QYqZkyzC2gw9Z7rxE0Z5+b/b/cV0VPhF7kJTvoyDG+J02PzEL4MKVm7rALc27+dKydqH7RI2sXeHY/HJJ3vN2iwtB2nwAjkdxZZCcfRN0a2keFz7lCvL5iUdAUR6KwhIZ99kSPkSrYKEopmowPjkGDpi5U1MN7ur2w4FEDrsyWv+sG6QZiC7Te6bTvxyLZpF3ed8nAENtSVUXl5xNWXIjhtpbmES8hcMS+bgLT8RAakytgdJgl3X6Q2DTp9uyy8sKHPGUSIbg0JFhoDmErHfJnEXptu3l8qNGOWdtHXe71EAtYEktxobFJm+5Dn0ypoIsEQZaQdL7iDm6TKW2jvHMFAQFHZl/7tTo/oI3kpLt5N11LhCYeZ69t2zP9od2LCVtsM0yPYCOZFNYte5pzu4mFyBxYODJ+4QMffoTWajdskW0yReh/MItdFgT+c6 BNC9rq/f 7Udn92spUeruPjPG7+w4bLRdxjWS3kBOquluqPnfLj2NvWZOu7NlQto/VyR7F+cMG25XhDvjAsRhDSLnHyQKsMGBFCsrG1xuApBpVqe9KYh3Zr9MsU45HP0dwOooppLLgMn488x62zgDv//D3Ifn13s9oscGI9d7iBT79quu/RmuNBwHfBb6fEaceOLlq3L9BmwI8S0M0/oRCz7k7XyOVQpnk4hak6dWchBL52S/RlKVqBqJpdUx8lQWawycj5t5Mtsybr/HCGzndh79I9SL5LyoMPbuaUKCF7PHHtFRiiVUwjdLKeMopRObMs+5gODUigB/7 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 Fri, Feb 16, 2024 at 8:57=E2=80=AFAM Vlastimil Babka wr= ote: > > On 2/12/24 22:38, Suren Baghdasaryan wrote: > > Introduce CONFIG_MEM_ALLOC_PROFILING which provides definitions to easi= ly > > instrument memory allocators. It registers an "alloc_tags" codetag type > > with /proc/allocinfo interface to output allocation tag information whe= n > > the feature is enabled. > > CONFIG_MEM_ALLOC_PROFILING_DEBUG is provided for debugging the memory > > allocation profiling instrumentation. > > Memory allocation profiling can be enabled or disabled at runtime using > > /proc/sys/vm/mem_profiling sysctl when CONFIG_MEM_ALLOC_PROFILING_DEBUG= =3Dn. > > CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT enables memory allocation > > profiling by default. > > > > Signed-off-by: Suren Baghdasaryan > > Co-developed-by: Kent Overstreet > > Signed-off-by: Kent Overstreet > > --- > > Documentation/admin-guide/sysctl/vm.rst | 16 +++ > > Documentation/filesystems/proc.rst | 28 +++++ > > include/asm-generic/codetag.lds.h | 14 +++ > > include/asm-generic/vmlinux.lds.h | 3 + > > include/linux/alloc_tag.h | 133 ++++++++++++++++++++ > > include/linux/sched.h | 24 ++++ > > lib/Kconfig.debug | 25 ++++ > > lib/Makefile | 2 + > > lib/alloc_tag.c | 158 ++++++++++++++++++++++++ > > scripts/module.lds.S | 7 ++ > > 10 files changed, 410 insertions(+) > > create mode 100644 include/asm-generic/codetag.lds.h > > create mode 100644 include/linux/alloc_tag.h > > create mode 100644 lib/alloc_tag.c > > > > diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/ad= min-guide/sysctl/vm.rst > > index c59889de122b..a214719492ea 100644 > > --- a/Documentation/admin-guide/sysctl/vm.rst > > +++ b/Documentation/admin-guide/sysctl/vm.rst > > @@ -43,6 +43,7 @@ Currently, these files are in /proc/sys/vm: > > - legacy_va_layout > > - lowmem_reserve_ratio > > - max_map_count > > +- mem_profiling (only if CONFIG_MEM_ALLOC_PROFILING=3Dy) > > - memory_failure_early_kill > > - memory_failure_recovery > > - min_free_kbytes > > @@ -425,6 +426,21 @@ e.g., up to one or two maps per allocation. > > The default value is 65530. > > > > > > +mem_profiling > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + > > +Enable memory profiling (when CONFIG_MEM_ALLOC_PROFILING=3Dy) > > + > > +1: Enable memory profiling. > > + > > +0: Disabld memory profiling. > > Disable Ack. > > ... > > > +allocinfo > > +~~~~~~~ > > + > > +Provides information about memory allocations at all locations in the = code > > +base. Each allocation in the code is identified by its source file, li= ne > > +number, module and the function calling the allocation. The number of = bytes > > +allocated at each location is reported. > > See, it even says "number of bytes" :) Yes, we are changing the output to bytes. > > > + > > +Example output. > > + > > +:: > > + > > + > cat /proc/allocinfo > > + > > + 153MiB mm/slub.c:1826 module:slub func:alloc_slab_page > > Is "module" meant in the usual kernel module sense? In that case IIRC is > more common to annotate things e.g. [xfs] in case it's really a module, a= nd > nothing if it's built it, such as slub. Is that "slub" simply derived fro= m > "mm/slub.c"? Then it's just redundant? Sounds good. The new example would look like this: > sort -rn /proc/allocinfo 127664128 31168 mm/page_ext.c:270 func:alloc_page_ext 56373248 4737 mm/slub.c:2259 func:alloc_slab_page 14880768 3633 mm/readahead.c:247 func:page_cache_ra_unbounded 14417920 3520 mm/mm_init.c:2530 func:alloc_large_system_hash 13377536 234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs 11718656 2861 mm/filemap.c:1919 func:__filemap_get_folio 9192960 2800 kernel/fork.c:307 func:alloc_thread_stack_node 4206592 4 net/netfilter/nf_conntrack_core.c:2567 func:nf_ct_alloc_hashtable 4136960 1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] func:ctagmod_start 3940352 962 mm/memory.c:4214 func:alloc_anon_folio 2894464 22613 fs/kernfs/dir.c:615 func:__kernfs_new_node ... Note that [ctagmod] is the only allocation from a module in this example. > > > + 6.08MiB mm/slab_common.c:950 module:slab_common func:_kmalloc= _order > > + 5.09MiB mm/memcontrol.c:2814 module:memcontrol func:alloc_sla= b_obj_exts > > + 4.54MiB mm/page_alloc.c:5777 module:page_alloc func:alloc_pag= es_exact > > + 1.32MiB include/asm-generic/pgalloc.h:63 module:pgtable func:= __pte_alloc_one > > + 1.16MiB fs/xfs/xfs_log_priv.h:700 module:xfs func:xlog_kvmall= oc > > + 1.00MiB mm/swap_cgroup.c:48 module:swap_cgroup func:swap_cgro= up_prepare > > + 734KiB fs/xfs/kmem.c:20 module:xfs func:kmem_alloc > > + 640KiB kernel/rcu/tree.c:3184 module:tree func:fill_page_cac= he_func > > + 640KiB drivers/char/virtio_console.c:452 module:virtio_conso= le func:alloc_buf > > + ... > > + > > + > > meminfo > > ... > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 0be2d00c3696..78d258ca508f 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -972,6 +972,31 @@ config CODE_TAGGING > > bool > > select KALLSYMS > > > > +config MEM_ALLOC_PROFILING > > + bool "Enable memory allocation profiling" > > + default n > > + depends on PROC_FS > > + depends on !DEBUG_FORCE_WEAK_PER_CPU > > + select CODE_TAGGING > > + help > > + Track allocation source code and record total allocation size > > + initiated at that code location. The mechanism can be used to t= rack > > + memory leaks with a low performance and memory impact. > > + > > +config MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT > > + bool "Enable memory allocation profiling by default" > > + default y > > I'd go with default n as that I'd select for a general distro. Well, we have MEM_ALLOC_PROFILING=3Dn by default, so if it was switched on manually, that is a strong sign that the user wants it enabled IMO. So, enabling this switch by default seems logical to me. If a distro wants to have the feature compiled in but disabled by default then this is perfectly doable, just need to set both options appropriately. Does my logic make sense? > > > + depends on MEM_ALLOC_PROFILING > > + > > +config MEM_ALLOC_PROFILING_DEBUG > > + bool "Memory allocation profiler debugging" > > + default n > > + depends on MEM_ALLOC_PROFILING > > + select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT > > + help > > + Adds warnings with helpful error messages for memory allocation > > + profiling. > > + >