[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251128110416.GR4068168@noisy.programming.kicks-ass.net>
Date: Fri, 28 Nov 2025 12:04:16 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: mingo@...nel.org, vincent.guittot@...aro.org,
Paul McKenney <paulmck@...nel.org>
Cc: linux-kernel@...r.kernel.org, juri.lelli@...hat.com,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, tj@...nel.org,
void@...ifault.com, arighi@...dia.com, changwoo@...lia.com,
sched-ext@...ts.linux.dev
Subject: Re: [PATCH 3/5] sched: Change rcu_dereference_check_sched_domain()
to rcu-sched
On Fri, Nov 28, 2025 at 11:57:23AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 27, 2025 at 04:39:46PM +0100, Peter Zijlstra wrote:
> > By changing rcu_dereference_check_sched_domain() to use
> > rcu_dereference_sched_check() it also considers preempt_disable() to
> > be equivalent to rcu_read_lock().
> >
> > Since rcu fully implies rcu_sched this has absolutely no change in
> > behaviour, but it does allow removing a bunch of otherwise redundant
> > rcu_read_lock() noise.
>
> This goes sideways with NUMABALANCING=y, it needs a little more. I'll
> have a poke.
Bah, so I overlooked that rcu_dereference_sched() checks
rcu_sched_lock_map while rcu_dereference() checks rcu_lock_map.
Paul, with RCU being unified, how much sense does it make that the rcu
validation stuff is still fully separated?
Case at hand, I'm trying to remove a bunch of
rcu_read_lock()/rcu_read_unlock() noise from deep inside the scheduler
where I know IRQs are disabled.
But the rcu checking thing is still living in the separated universe and
giving me pain.
Powered by blists - more mailing lists