From: Peter Zijlstra <peterz@infradead.org>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-kernel@vger.kernel.org,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Swapnil Sapkal <swapnil.sapkal@amd.com>
Subject: Re: [RFC PATCH 5/5] sched/fair: Proactive idle balance using push mechanism
Date: Thu, 10 Apr 2025 12:29:45 +0200 [thread overview]
Message-ID: <20250410102945.GD30687@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250409111539.23791-6-kprateek.nayak@amd.com>
On Wed, Apr 09, 2025 at 11:15:39AM +0000, K Prateek Nayak wrote:
> Proactively try to push tasks to one of the CPUs set in the
> "nohz.idle_cpus_mask" from the push callback.
>
> pick_next_pushable_fair_task() is taken from Vincent's series [1] as is
> but the locking rules in push_fair_task() has been relaxed to release
> the local rq lock after dequeuing the task and reacquiring it after
> pushing it to the idle target.
>
> double_lock_balance() used in RT seems necessary to maintain strict
> priority ordering however that may not be necessary for fair tasks.
Agreed; don't use double_lock_balance() if you can at all avoid it. It
is quite terrible.
> /*
> * See if the non running fair tasks on this rq can be sent on other CPUs
> * that fits better with their profile.
> */
> static bool push_fair_task(struct rq *rq)
> {
> + struct cpumask *cpus = this_cpu_cpumask_var_ptr(load_balance_mask);
> + struct task_struct *p = pick_next_pushable_fair_task(rq);
> + int cpu, this_cpu = cpu_of(rq);
> +
> + if (!p)
> + return false;
> +
> + if (!cpumask_and(cpus, nohz.idle_cpus_mask, housekeeping_cpumask(HK_TYPE_KERNEL_NOISE)))
> + goto requeue;
So I think the main goal here should be to get rid of the whole single
nohz balancing thing.
This global state/mask has been shown to be a problem over and over again.
Ideally we keep a nohz idle mask per LLC (right next to the overload
mask you introduced earlier), along with a bit in the sched_domain tree
upwards of that to indicate a particular llc/ node / distance-group has
nohz idle.
Then if the topmost domain has the bit set it means there are nohz cpus
to be found, and we can (slowly) iterate the domain tree up from
overloaded LLC to push tasks around.
Anyway, yes, you gotta start somewhere :-)
next prev parent reply other threads:[~2025-04-10 10:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 11:15 [RFC PATCH 0/5] K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 1/5] sched/fair: Add push task framework K Prateek Nayak
2025-04-10 10:00 ` Peter Zijlstra
2025-04-10 15:25 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 2/5] sched/fair: Introduce overloaded_mask in sched_domain_shared K Prateek Nayak
2025-04-10 10:03 ` Peter Zijlstra
2025-04-10 15:26 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 3/5] sched/fair: Update overloaded mask in presence of pushable task K Prateek Nayak
2025-04-14 2:28 ` Aaron Lu
2025-04-14 3:13 ` K Prateek Nayak
2025-04-21 5:20 ` Shrikanth Hegde
2025-04-21 5:54 ` K Prateek Nayak
2025-04-21 8:03 ` Shrikanth Hegde
2025-04-21 8:54 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 4/5] sched/fair: Rework inter-NUMA newidle balancing K Prateek Nayak
2025-04-10 10:14 ` Peter Zijlstra
2025-04-10 15:27 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 5/5] sched/fair: Proactive idle balance using push mechanism K Prateek Nayak
2025-04-10 10:29 ` Peter Zijlstra [this message]
2025-04-10 15:37 ` K Prateek Nayak
2025-04-09 11:17 ` [RFC PATCH 0/5] sched/fair: Idle and newidle balancing " K Prateek Nayak
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=20250410102945.GD30687@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=swapnil.sapkal@amd.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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