From nobody Sun Feb 8 02:41:08 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D43B30FF28 for ; Tue, 16 Dec 2025 06:44:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765867507; cv=none; b=cEtWDgRQ5M+B1+tV89ZVsvEr4j4s9kPj7sUMOT6jifhbZ5rf64KLNPO3kDNjPAmQjfXJR0JnyXbGFfz8NtXc9VyIuMzSvhuNgsMZsrL5VlgLw4viHItYo3d+1oWu0UXtuo4Ezen9kq0ieJsdzcsEShuJR1lAzb8CjXp4ezcy+XA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765867507; c=relaxed/simple; bh=tTV6Rrr+N9tWvcxpmautzgU4zCQVn7S/hfE6slzRLJc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JVI9xldwSY6f6xwn0X+uahfMWvIdx5OMTDtlcz/yxlqjYsxagRss0jjIDvezI3xk7yp7i334PdAFOlmZ0CdLN38+vPJZYodw7inO2es03mqafAXSdIWOqpQdkxyKdi0R1ooH4IRNA/Iin447LSuHaXoQOGpF8ZS+Y4SUSSMr+YI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=bbxLGiXZ; arc=none smtp.client-ip=117.135.210.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="bbxLGiXZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=vy O0oppduEkgyqxUeWeOfgKgDxGnIfMor6OnxIu/1ho=; b=bbxLGiXZn5yZZSPMvT UJ4Jfcs+5+9TVr6BbY1DZesmDSdMcZLKKq6ReBdldFgG8Y6F20iCPztGFGQSvg/x BN7dZaMeDpW3YMlCCI0CbqX065YFVHVTFJy63aJkjR+0MWIcWXVEcooHKVMJM2oX NyOo7bjQOp/VxvAmiPA7sX6l8= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wD3Xxqp_0Bpf1fCAg--.4065S4; Tue, 16 Dec 2025 14:44:07 +0800 (CST) From: David Wang <00107082@163.com> To: surenb@google.com, kent.overstreet@linux.dev Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, pasha.tatashin@soleen.com, souravpanda@google.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Wang <00107082@163.com> Subject: [PATCH RFC] alloc_tag: add option to pick the first codetag along callchain Date: Tue, 16 Dec 2025 14:43:49 +0800 Message-ID: <20251216064349.74501-1-00107082@163.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3Xxqp_0Bpf1fCAg--.4065S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxCr13urW7Xr17ZF4DJrWxXrb_yoW5WryDpa n5W3W8GFs5Xw1fGryxCw1xKr1fu3yIkrWYqFWI9w18uFZIyF429r1DKrW2va4DCr4vyF4j qrZakrWxKF1DAw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0piJGYdUUUUU= X-CM-SenderInfo: qqqrilqqysqiywtou0bp/xtbCxRiYQ2lA-7h4IQAA3x Content-Type: text/plain; charset="utf-8" When tracking memory allocation for some specific function, picking the first codetag is more desired, because there is no need to track down all allocation sites in the call graph and change them to _noprof version, which is quite inflexible when the call graph is complex. For example, consider a simple graph: A ---> B ---> C =3D=3D=3D> D E ---> C =3D=3D=3D> means a call with codetag ---> means a call without codetag To profiling memory allocation for A, the call graph needs to be changed to A =3D=3D=3D> B ---> C ---> D E =3D=3D=3D> C Three call sites needs to be changed. But if pick the first codetag, only one change is needed. A =3D=3D=3D> B ---> C =3D=3D=3D> D E ---> C The drawback is some accounting for C is splited to A, making the number not accurate for C. (But the overall accounting is still the same.) This is useful when debug memory problems, not meant for production usage though. Signed-off-by: David Wang <00107082@163.com> --- include/linux/sched.h | 6 ++++++ lib/Kconfig.debug | 12 ++++++++++++ 2 files changed, 18 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index d395f2810fac..4a4f7000737e 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -2288,14 +2288,20 @@ extern void sched_set_stop_task(int cpu, struct tas= k_struct *stop); #ifdef CONFIG_MEM_ALLOC_PROFILING static __always_inline struct alloc_tag *alloc_tag_save(struct alloc_tag *= tag) { +#ifdef CONFIG_MEM_ALLOC_PROFILING_PICK_FIRST_CODETAG + if (current->alloc_tag) + return current->alloc_tag; +#endif swap(current->alloc_tag, tag); return tag; } =20 static __always_inline void alloc_tag_restore(struct alloc_tag *tag, struc= t alloc_tag *old) { +#ifndef CONFIG_MEM_ALLOC_PROFILING_PICK_FIRST_CODETAG #ifdef CONFIG_MEM_ALLOC_PROFILING_DEBUG WARN(current->alloc_tag !=3D tag, "current->alloc_tag was changed:\n"); +#endif #endif current->alloc_tag =3D old; } diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ba36939fda79..6e6f3a12033a 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1038,6 +1038,18 @@ config MEM_ALLOC_PROFILING_DEBUG Adds warnings with helpful error messages for memory allocation profiling. =20 +config MEM_ALLOC_PROFILING_PICK_FIRST_CODETAG + bool "Use the first tag along the call chain" + default n + depends on MEM_ALLOC_PROFILING + select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT + help + Make memory allocation profiling store counters to the first + codetag along the call chain. This help profiling memory allocation + for specific function by simply adding codetag to the function, + without clearup all the codetag down the callchain. + It is used for debug purpose. + source "lib/Kconfig.kasan" source "lib/Kconfig.kfence" source "lib/Kconfig.kmsan" --=20 2.47.3