public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	"Chen, Yu C" <yu.c.chen@intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Doug Nelson <doug.nelson@intel.com>,
	Mohini Narkhede <mohini.narkhede@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: Skip useless sched_balance_running acquisition if load balance is not due
Date: Fri, 18 Apr 2025 11:28:28 +0200	[thread overview]
Message-ID: <20250418092828.GP38216@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <87728994-b928-45b3-a6a0-258af6e81294@amd.com>

On Fri, Apr 18, 2025 at 10:56:04AM +0530, K Prateek Nayak wrote:
> Hello Peter,
> 
> On 4/17/2025 5:31 PM, Peter Zijlstra wrote:
> > > o Since this is a single flag across the entire system, it also implies
> > >    CPUs cannon concurrently do load balancing across different NUMA
> > >    domains which seems reasonable since a load balance at lower NUMA
> > >    domain can potentially change the "nr_numa_running" and
> > >    "nr_preferred_running" stats for the higher domain but if this is the
> > >    case, a newidle balance at lower NUMA domain can interfere with a
> > >    concurrent busy / newidle load balancing at higher NUMA domain.
> > >    Is this expected? Should newidle balance be serialized too?
> > 
> > Serializing new-idle might create too much idle time.
> 
> In the context of busy and idle balancing, What are your thoughts on a
> per sd "serialize' flag?

My sekret hope is that this push stuff can rid us all the idle balance
bits. But yeah, early days on that.

Other than that, I don't quite see why we should split that, busy
balancing is the one that runs more often and is the one that should be
serialized to avoid too much cross node traffic and all that, no?

The idle thing is less often, why not limit that?

  reply	other threads:[~2025-04-18  9:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16  3:58 [PATCH] sched: Skip useless sched_balance_running acquisition if load balance is not due Tim Chen
2025-04-16  5:30 ` Shrikanth Hegde
2025-04-16  6:28   ` Chen, Yu C
2025-04-16  9:16     ` Shrikanth Hegde
2025-04-16  9:29       ` Shrikanth Hegde
2025-04-16  9:47         ` Vincent Guittot
2025-04-16 14:14           ` Shrikanth Hegde
2025-04-17 11:10             ` K Prateek Nayak
2025-04-18 15:02             ` Vincent Guittot
2025-04-18 17:55               ` Shrikanth Hegde
2025-04-17 11:31           ` K Prateek Nayak
2025-04-17 12:01             ` Peter Zijlstra
2025-04-18  5:26               ` K Prateek Nayak
2025-04-18  9:28                 ` Peter Zijlstra [this message]
2025-04-18 12:13                   ` K Prateek Nayak
2025-04-16 16:19       ` Tim Chen
2025-04-16 17:11         ` Shrikanth Hegde
2025-04-17  9:19         ` Shrikanth Hegde
2025-04-17 17:12           ` Tim Chen
2025-05-29  9:00 ` K Prateek Nayak
2025-06-04  4:26 ` Chen, Yu C
2025-06-06 13:51 ` Vincent Guittot
2025-10-27 18:06   ` Mel Gorman

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=20250418092828.GP38216@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --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=sshegde@linux.ibm.com \
    --cc=tim.c.chen@linux.intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox