All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>, Chen Yu <yu.c.chen@intel.com>,
	Doug Nelson <doug.nelson@intel.com>,
	Mohini Narkhede <mohini.narkhede@intel.com>,
	linux-kernel@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>
Subject: Re: [PATCH v4] sched/fair: Skip sched_balance_running cmpxchg when balance is not due
Date: Wed, 12 Nov 2025 21:32:04 +0530	[thread overview]
Message-ID: <aRSvfJmQTGfdS0fc@linux.ibm.com> (raw)
In-Reply-To: <20251112133937.GC3245006@noisy.programming.kicks-ass.net>

* Peter Zijlstra <peterz@infradead.org> [2025-11-12 14:39:37]:

> On Wed, Nov 12, 2025 at 04:55:48PM +0530, Srikar Dronamraju wrote:
> 
> > If the CPU that was doing the balance was not the first CPU of the domain
> > span, but it was doing the balance since the first CPU was busy, and the
> > first CPU now happens to be idle at redo, the scheduler would have chosen the
> > first CPU to do the balance. However it will now choose the CPU that had the atomic..
> > 
> > I think this is better because 
> > - The first CPU may have tried just before this CPU dropped the atomic and
> >   hence we may miss the balance opportunity.
> > - The first CPU and the other CPU may not be sharing cache and hence there
> >   may be a cache-miss, which we are avoiding by doing this.
> 
> I'm not sure I understand what you're arguing for. Are you saying it
> would be better to retain the lock where possible?
> 

Yes, I was supporting keeping the lock and not check should_we_balance() with
lock held.

Lets say CPU2 enters sched_balance_rq(), should_we_balance succeeds, CPU 2 take
the lock. It calls redo, and this time should_we_balance() may not succeed for
CPU 2 (since CPU 0/1 is idle). However CPU0 may have already raced with CPU2
and tried to take the lock before CPU2 released it and bailed out. So we miss a
balancing opportunity.

> 

-- 
Thanks and Regards
Srikar Dronamraju

  parent reply	other threads:[~2025-11-12 16:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-10 18:47 [PATCH v4] sched/fair: Skip sched_balance_running cmpxchg when balance is not due Tim Chen
2025-11-11  6:24 ` Shrikanth Hegde
2025-11-12  8:02 ` Srikar Dronamraju
2025-11-12 10:37   ` Peter Zijlstra
2025-11-12 10:45     ` Peter Zijlstra
2025-11-12 11:09       ` Shrikanth Hegde
2025-11-12 11:21         ` Peter Zijlstra
2025-11-12 21:10           ` Tim Chen
2025-11-13  4:25             ` Shrikanth Hegde
2025-11-13 17:49               ` Tim Chen
2025-11-12 11:25       ` Srikar Dronamraju
2025-11-12 13:39         ` Peter Zijlstra
2025-11-12 13:44           ` Peter Zijlstra
2025-11-12 16:02           ` Srikar Dronamraju [this message]
2025-11-12 10:53     ` Shrikanth Hegde
2025-11-14 12:19 ` [tip: sched/core] " tip-bot2 for Tim Chen
2025-11-15 20:56   ` Shrikanth Hegde
2025-11-17 18:55     ` Tim Chen
2025-11-17 19:00       ` K Prateek Nayak
2025-11-27 14:09         ` Peter Zijlstra
2025-11-18  9:54       ` Peter Zijlstra
2025-11-18  9:56         ` Peter Zijlstra
2025-11-21  6:26         ` Nathan Chancellor
2025-11-21  9:00           ` Peter Zijlstra
2025-11-17 19:06     ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aRSvfJmQTGfdS0fc@linux.ibm.com \
    --to=srikar@linux.ibm.com \
    --cc=doug.nelson@intel.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mohini.narkhede@intel.com \
    --cc=peterz@infradead.org \
    --cc=sshegde@linux.ibm.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.guittot@linaro.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.