[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250423213343.6c5dd621@gandalf.local.home>
Date: Wed, 23 Apr 2025 21:33:43 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Libo Chen <libo.chen@...cle.com>
Cc: akpm@...ux-foundation.org, peterz@...radead.org, mgorman@...e.de,
mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
tj@...nel.org, llong@...hat.com, sraithal@....com, venkat88@...ux.ibm.com,
kprateek.nayak@....com, raghavendra.kt@....com, yu.c.chen@...el.com,
tim.c.chen@...el.com, vineethr@...ux.ibm.com, chris.hyser@...cle.com,
daniel.m.jordan@...cle.com, lorenzo.stoakes@...cle.com, mkoutny@...e.com,
linux-mm@...ck.org, cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] sched/numa: Add tracepoint that tracks the
skipping of numa balancing due to cpuset memory pinning
On Wed, 23 Apr 2025 18:12:55 -0700
Libo Chen <libo.chen@...cle.com> wrote:
> > 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));
> >
>
> to guard against potential changes in nodemask_t definition?
Correct.
Whenever there's an implicit dependency like this, where if something were
to change it can cause a bug in the kernel, it's always better to have a
build time check to catch it before it becomes an issue.
-- Steve
Powered by blists - more mailing lists