From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
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 17:43:34 +0530 [thread overview]
Message-ID: <331fb3d6-33f3-4656-a134-3ab3a245e477@amd.com> (raw)
In-Reply-To: <20250418092828.GP38216@noisy.programming.kicks-ass.net>
Hello Peter,
On 4/18/2025 2:58 PM, Peter Zijlstra wrote:
> 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?
Makes sense. I'll add it to the set of my weekend experiment runs.
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2025-04-18 12:13 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
2025-04-18 12:13 ` K Prateek Nayak [this message]
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=331fb3d6-33f3-4656-a134-3ab3a245e477@amd.com \
--to=kprateek.nayak@amd.com \
--cc=doug.nelson@intel.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=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.