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 EC882C369CB for ; Thu, 24 Apr 2025 00:59:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEE646B0006; Wed, 23 Apr 2025 20:59:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9BE56B0007; Wed, 23 Apr 2025 20:59:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB3896B0008; Wed, 23 Apr 2025 20:59:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8C8306B0006 for ; Wed, 23 Apr 2025 20:59:20 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 95F78160B3A for ; Thu, 24 Apr 2025 00:59:20 +0000 (UTC) X-FDA: 83367128880.24.D63AD9D Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf10.hostedemail.com (Postfix) with ESMTP id 06513C0008 for ; Thu, 24 Apr 2025 00:59:18 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=aaZh=XK=goodmis.org=rostedt@kernel.org" designates 172.105.4.254 as permitted sender) smtp.mailfrom="SRS0=aaZh=XK=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745456359; a=rsa-sha256; cv=none; b=E2F2yZRk7WEXWj3KLzIKn6yIEJ1kZyDW5BrokryW2BHbeVp+DVdwYw56/toNZG8+I8LaZa sdoHOKWXQppYCd+ot3SmkUlK25Kb/+sbG7KDrswAYkLmYr28of9leHKIiDld1jYW0vSOyV uO8iyFLYSGCyyGsRkSns9aMtjZYXYlI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=aaZh=XK=goodmis.org=rostedt@kernel.org" designates 172.105.4.254 as permitted sender) smtp.mailfrom="SRS0=aaZh=XK=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745456359; 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; bh=AZGIBH43LYAigzVBouVA5lmn0KCQxfwdY/PW+fuDwRM=; b=wBkGH3MtbZ4/wxuiE93hv/QhF/VgtUxh5a45SlflCLAUbyPFRIsVbivj/BkFbl3dXNmQqF kbQj/zq4E0tmaJFxsP4DdIpunRXKTrNFe0gaXR+iIGKut9Qo2p0puCN7UzAf8fTa7qwzor jrdFq5LjBkD5w0A79eaNBC4pOj1J4u4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id DC5D568453; Thu, 24 Apr 2025 00:58:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F092BC4CEE2; Thu, 24 Apr 2025 00:59:14 +0000 (UTC) Date: Wed, 23 Apr 2025 21:01:08 -0400 From: Steven Rostedt To: Libo Chen Cc: akpm@linux-foundation.org, peterz@infradead.org, mgorman@suse.de, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, tj@kernel.org, llong@redhat.com, sraithal@amd.com, venkat88@linux.ibm.com, kprateek.nayak@amd.com, raghavendra.kt@amd.com, yu.c.chen@intel.com, tim.c.chen@intel.com, vineethr@linux.ibm.com, chris.hyser@oracle.com, daniel.m.jordan@oracle.com, lorenzo.stoakes@oracle.com, mkoutny@suse.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] sched/numa: Add tracepoint that tracks the skipping of numa balancing due to cpuset memory pinning Message-ID: <20250423210108.5b2452ad@gandalf.local.home> In-Reply-To: References: <20250424000146.1197285-1-libo.chen@oracle.com> <20250424000146.1197285-3-libo.chen@oracle.com> <20250423201829.17d4c382@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (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-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 06513C0008 X-Stat-Signature: 67d7bzh6kc7pd1d4njj1nn88rzkw446c X-Rspam-User: X-HE-Tag: 1745456358-505166 X-HE-Meta: U2FsdGVkX187KCl/tdf+Fac/6xySB2xns/FpdE47ZGSGkLCKjKvVSPQSDJZRf1mq+05aEYS8xpPBUS4xXsuZ0faeVXRj5VJLI64dThZOHjtj8YwTlgIs+BHZQeVla2sCmTMcBpo2+UsTS/vvFmuc4Lu9s9uQpiPTt7HQtW6m6lVL0W7TLRXYO3fEn29qAz67AOsNk/c2EeJyGAQVxYi9wSExNjhZsEXd8JprCvmv/d167Mkdj9IJiWceRCA1zZS5lOiK8jBkCwB63GIEV2GYngj7gDX8wcHJjDGF7MFpsj69OHXFTMDoCj0uRLptA/eIBdnE8HPaR5pVJ6IJLhI6XMFoIET7kGaP7reyEBRsD400SYxf9K1vLcnWTm4v8QnMVuNuXx0ez5tBHr3KcYe/FwRlMar8vVB4TmG5+LEampcj9WWFZ+yxCmepIYEkre+KOsl+rQsI2GAcoOyaxexSzH1HR4MnAwhUzbDoefBep8SOEZuY1Pts2Zr9D7hZdgbGQzrBdj0E9vLMGnfeIBUFhqEJwOzyhJ4Rlq780YFk9tn3ttIDz/wfssxX1Z+I3aRE3laFk1N/YIbVnLoMvH/6qdIolZ/T0lF/AyxzltQeC0KEaxaBoB0jH8KoxbDXvk/wx1pGCX4Kfzd8Fa9c031I3+0IsGoHmNK2obQpDu5bDYuvUJH55IKCFDHFIM7hhC0dgQCJESU3yXoUek3/unH5qhE5cr4Mdb+XFfLJ7fnD8QCCbG1MF81A+TEmmmFCTIJC5rdC0+2NMQ+VhhawfUC+PKVk8ZphxBlU8HdP1nVK/HGK8eZ5l/6pW2zBcel0O8AvG2egEeb3TQeOScsqofrKqfVLnVe4ER9UnunzKs2xgBvO3Syc9k47ZiH1w0VCiWI6KKVtbi5VZ8IuXMCC0qeAkZaxidNR0BXiO8lz8b5s1MgQOUx2YDdwjCeaqaaBfHZm7ewdJsFWpXVyppvQK1l qsjQ8F00 njB53dO1mOWxXQRAdKtBXGqOswUAFvvTeT+fUpDW6N/UXmUPsMmr85ajDJkJgYo+HqYrZEtQ00kqG+V0miGGHc+KX3z4rpNP0ciMA/kFW1zLQsfUH24dxhH0fqllL0QFTw4bF0e8xn7sc2G+zkPAiQsWwD6+vqrIHTRXpWXqQX4yC7uUR1lPLLtvOeHwIqCW+0yi3kbgBnP2hIsFhlsYeFzd6uWq0ZgHqJPKtlrThsYQTpWe6gmYsw/SSozSrCRvS2E4CHnGnUoFZTbv6zW1Yxa6PQw== 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 Wed, 23 Apr 2025 17:36:30 -0700 Libo Chen wrote: > >> + TP_fast_assign( > >> + memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN); > >> + __entry->pid = task_pid_nr(tsk); > >> + __entry->tgid = task_tgid_nr(tsk); > >> + __entry->ngid = task_numa_group_id(tsk); > >> + memcpy(__entry->mem_allowed, mem_allowed_ptr->bits, > >> + sizeof(__entry->mem_allowed)); > > > > Is mem_allowed->bits guaranteed to be the size of BITS_TO_LONGS(MAX_NUM_NODES) > > in size? If not, then memcpy will read beyond that size. > > > > Yes, evidence can be found in the definitions of nodemask_t and DECLARE_BITMAP: > > // include/linux/nodemask_types.h > typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t; > > // include/linux/types.h > #define DECLARE_BITMAP(name,bits) \ > unsigned long name[BITS_TO_LONGS(bits)] > Hmm, I wonder then if we should add in TP_fast_assign(): BUILD_BUG_ON(sizeof(nodemask_t) != BITS_TO_LONGS(MAX_NUM_NODES) * sizeof(long)); -- Steve