From: Peter Zijlstra <peterz@infradead.org>
To: Aaron Lu <ziqianlu@bytedance.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
kprateek.nayak@amd.com, tj@kernel.org, williams@redhat.com,
jkacur@redhat.com
Subject: Re: [PATCH 0/2] sched: Remove sched_class::balance()
Date: Wed, 19 Aug 2026 16:36:49 +0200 [thread overview]
Message-ID: <20260819143649.GB1248307@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260819075830.GF1246887@noisy.programming.kicks-ass.net>
On Wed, Aug 19, 2026 at 09:58:30AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 02, 2026 at 07:49:19PM +0800, Aaron Lu wrote:
>
> > Assume cpuX and cpuY are siblings, it appears the following happened:
> >
> > cpuX cpuY
> >
> > pick_next_task()
> > goto restart_multi
> >
> > rqX->core_pick = pick_task(rqX)
> >
> > pick_task(rqY)
> > pick_task_fair(rqY)
> > sched_balance_newidle(rqY)
> > raw_spin_rq_unlock(rqY) // drops core lock
> >
> > pick_next_task()
> > goto restart_multi
> > rqY->core_pick = pick_task(rqY)
> > rqX->core_pick = pick_task(rqX)
> >
> > if (rqX->curr == rqX->core_pick)
> > rqX->core_pick = NULL
> >
> > UNLOCK rq_lockp(rqY)
> >
> > raw_spin_rq_lock(rqY)
> >
> > rqY->core_pick = pick_task(rqY)
> >
> > p = rqX->core_pick // NULL
> > cookie_equals(p, cookie) // NULL deref
>
> Well, damn :/ That's a nice race. So while we did a lock-break, it does
> not trigger RETRY_TASK and continues.
>
> The 'easy' fix is taking a local copy of core_task_seq when we increase
> it for the pick, and double checking that is still valid at the end and
> then restarting if not.
>
> Except that is susceptible to live-locks. It doesn't have forward
> progress guarantees. For that we need to limit the amount of
> lock-breaks/newidle invocations.
So TJ did something like that for ext. I'm not entirely sure I get his
argument on forward progress though.
But the simple thing is something like so, which I think also allows
simplifying ext some.
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8070a347cf3b..ce8bb5036fe1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6232,14 +6232,14 @@ static struct task_struct *
pick_next_task(struct rq *rq, struct rq_flags *rf)
__must_hold(__rq_lockp(rq))
{
+ bool core_clock_updated = (rq == rq->core);
struct task_struct *next, *p, *max;
const struct cpumask *smt_mask;
+ int i, cpu, seq, occ = 0;
bool fi_before = false;
- bool core_clock_updated = (rq == rq->core);
- unsigned long cookie;
- int i, cpu, occ = 0;
- struct rq *rq_i;
bool need_sync = false;
+ unsigned long cookie;
+ struct rq *rq_i;
if (!sched_core_enabled(rq))
return __pick_next_task(rq, rf);
@@ -6314,7 +6314,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
* However, preemptions can cause multiple picks on the same task set.
* 'Fix' this by also increasing @task_seq for every pick.
*/
- rq->core->core_task_seq++;
+ seq = ++rq->core->core_task_seq;
/*
* Optimize for common case where this CPU has no cookies
@@ -6362,7 +6362,8 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
update_rq_clock(rq_i);
p = pick_task(rq_i, rf);
- if (unlikely(p == RETRY_TASK)) {
+ if (unlikely(seq != rq->core->core_task_seq ||
+ WARN_ON_ONCE(p == RETRY_TASK))) {
/* rq lock may have been dropped, clocks invalidated */
core_clock_updated = false;
if (!(rq->clock_update_flags & RQCF_UPDATED))
@@ -6392,7 +6393,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
if (cookie)
p = sched_core_find(rq_i, cookie);
if (!p)
- p = idle_sched_class.pick_task(rq_i, rf);
+ p = idle_sched_class.pick_task(rq_i, NULL);
}
rq_i->core_pick = p;
next prev parent reply other threads:[~2026-08-19 14:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 12:13 Peter Zijlstra
2026-06-24 12:13 ` [PATCH 1/2] sched/core: Allow newidle for core-sched Peter Zijlstra
2026-06-24 23:56 ` K Prateek Nayak
2026-06-25 12:41 ` Peter Zijlstra
2026-06-25 12:42 ` Peter Zijlstra
2026-06-24 12:13 ` [PATCH 2/2] sched: Remove sched_class::balance() Peter Zijlstra
2026-07-02 11:49 ` [PATCH 0/2] " Aaron Lu
2026-07-03 3:31 ` K Prateek Nayak
2026-08-19 9:39 ` Peter Zijlstra
2026-08-19 7:58 ` Peter Zijlstra
2026-08-19 14:36 ` Peter Zijlstra [this message]
2026-08-19 19:22 ` Tejun Heo
2026-08-20 7:18 ` Peter Zijlstra
2026-08-20 7:42 ` Tejun Heo
2026-08-20 7:58 ` Peter Zijlstra
2026-08-20 15:40 ` Peter Zijlstra
2026-08-20 17:15 ` K Prateek Nayak
2026-08-21 7:10 ` Peter Zijlstra
2026-08-22 9:42 ` Peter Zijlstra
2026-08-21 2:44 ` Aaron Lu
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=20260819143649.GB1248307@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jkacur@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=williams@redhat.com \
--cc=ziqianlu@bytedance.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
all inboxes | Powered by JetHome®