[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c90ee040-4d2c-4f52-badf-0ad9127e61c3@oracle.com>
Date: Wed, 23 Apr 2025 18:41:48 -0700
From: Libo Chen <libo.chen@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
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 4/23/25 18:33, Steven Rostedt wrote:
> 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.
>
Okay that's reasonable. I will add it~
Powered by blists - more mailing lists