[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251112112113.GO278048@noisy.programming.kicks-ass.net>
Date: Wed, 12 Nov 2025 12:21:13 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>, Ingo Molnar <mingo@...nel.org>,
Chen Yu <yu.c.chen@...el.com>, Doug Nelson <doug.nelson@...el.com>,
Mohini Narkhede <mohini.narkhede@...el.com>,
linux-kernel@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
K Prateek Nayak <kprateek.nayak@....com>,
Srikar Dronamraju <srikar@...ux.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v4] sched/fair: Skip sched_balance_running cmpxchg when
balance is not due
On Wed, Nov 12, 2025 at 04:39:43PM +0530, Shrikanth Hegde wrote:
>
>
> > So perhaps this is the better option -- or did I overlook something with
> > should_we_balance? It doesn't look like that will make a different
> > decision on the retry.
> >
>
> I think in newidle balance, these checks are there in swb to bail of load balance.
> redo logic catches it right?
Urgh, my brain still thinks we're not serializing on newidle. Perhaps I
should make this 2 patches, one moving the serializing and one adding it
to newidle.
> env->dst_rq lock is taken only in attach_tasks, meanwhile, if the wakeup happened,
> pending would be set. is irq enabled or remote CPU can set ttwu_pending on this rq?
>
> if (env->idle == CPU_NEWLY_IDLE) {
> if (env->dst_rq->nr_running > 0 || env->dst_rq->ttwu_pending)
> return 0;
> return 1;
> }
Right, that could get tickled.
Powered by blists - more mailing lists