From: albin_yang@163.com
To: peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org
Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
kprateek.nayak@amd.com, kayracizmeci@gmail.com,
linux-kernel@vger.kernel.org, albin_yang@163.com,
albinwyang@tencent.com
Subject: [PATCH v2] sched/stats: Fix run_delay over-count for tasks parked on the runqueue while blocked
Date: Sat, 14 Nov 2026 17:26:37 +0800 [thread overview]
Message-ID: <20261114092637.3206631-1-albin_yang@163.com> (raw)
From: Wei Yang <albinwyang@tencent.com>
A task parked on the runqueue while blocked -- a proxy-exec donor migrated
to its mutex owner's CPU, or a DELAY_DEQUEUE sleeper migrated across CPUs --
is re-attached with activate_task(rq, p, ENQUEUE_NOCLOCK), i.e. without
ENQUEUE_RESTORE. That arms sched_info.last_queued although the task is not
waiting for a CPU, and sched_info_dequeue() charges the parked time as
run-queue wait when proxy_needs_return() dequeues the donor (TASK_WAKING)
on wakeup.
Use p->is_blocked as the primary indicator: sched_info_dequeue() drops
last_queued without charging while blocked; sched_info_enqueue() refreshes
it on every enqueue while blocked, so the stamp ends up at the real wakeup;
ttwu_runnable() adds an explicit sched_info_enqueue() call under the
existing !task_on_cpu() guard, for wakeups that have no enqueue of their
own. Delayed sleepers also have is_blocked set, so both cases are covered.
The p == current early return in try_to_wake_up() now documents why it
needs no sched_info_enqueue() call.
Both over-counts disappear with this patch, and run_delay still grows
normally for a runnable task contending for the CPU, so the counter is
alive rather than switched off.
Fixes: b049b81bdff6 ("sched: Handle blocked-waiter migration (and return migration)")
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Suggested-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Signed-off-by: Wei Yang <albinwyang@tencent.com>
---
v2: switch from the v1 !task_is_blocked() gate to the is_blocked based
approach proposed by Prateek Nayak. Subject widened: v1 only mentioned
proxy-migrated donors, while the same gating fixes both cases.
Measured with two CPUs used (CPU0/CPU1); run_delay is field 2 of
/proc/<tid>/schedstat:
proxy exec, donor migrated to the owner's CPU (~170 ms block)
unpatched 167.07 - 167.09 ms 5/5 migrated
patched 0.00 ms 20/20 migrated
same-cpu control 0.00 ms 0/5 not migrated
DELAY_DEQUEUE, sleeper migrated across CPUs (~150 ms sleep)
unpatched 147.94 - 147.99 ms 5/20
patched 0.00 ms 0/100
The DELAY_DEQUEUE reproducer self-checks (must reproduce unpatched) and
shows ~40 ms of run_delay growth per round throughout.
v1: https://lore.kernel.org/all/20261025130740.3324391-1-albin_yang@163.com/
Full test results and the discussion of the split:
https://lore.kernel.org/all/20261101143101.353033-1-albin_yang@163.com/
p->is_blocked was added by 4c2a20413d7f ("sched: Add is_blocked task flag")
and is only available from v7.2-rc1. The DELAY_DEQUEUE over-count goes back
to v6.12 (152e11f6df29) and still needs the sched_delayed based variant on
older stable trees; that is a separate, independent fix. A second Fixes:
tag would make the stable backport machinery try this on v6.12.y, where
is_blocked does not exist. Hence only one Fixes: tag above.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1a088d4576f5..bb7914b713b1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3962,6 +3962,8 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
* it should preempt the task that is current now.
*/
wakeup_preempt(rq, p, wake_flags | WF_TTWU_RQ);
+ /* Start accounting wait time. */
+ sched_info_enqueue(rq, p);
}
ttwu_do_wakeup(p);
return 1;
@@ -4357,6 +4359,11 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
if (!ttwu_state_match(p, state, &success))
goto out;
+ /*
+ * No sched_info_enqueue() here: current is running, not
+ * waiting for a CPU. If preempted, sched_info_switch() ->
+ * sched_info_depart() arms the wait clock instead.
+ */
trace_sched_waking(p);
ttwu_do_wakeup(p);
goto out;
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index ebe0a7765f98..84d1fb208740 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -240,6 +240,9 @@ static inline void sched_info_dequeue(struct rq *rq, struct task_struct *t)
{
unsigned long long delta = 0;
+ if (t->is_blocked)
+ t->sched_info.last_queued = 0;
+
if (!t->sched_info.last_queued)
return;
@@ -290,7 +293,7 @@ static void sched_info_arrive(struct rq *rq, struct task_struct *t)
*/
static inline void sched_info_enqueue(struct rq *rq, struct task_struct *t)
{
- if (!t->sched_info.last_queued)
+ if (!t->sched_info.last_queued || t->is_blocked)
t->sched_info.last_queued = rq_clock(rq);
}
--
2.43.7
next reply other threads:[~2026-11-14 9:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 9:26 albin_yang [this message]
2026-11-14 13:49 ` Kayra Cizmeci
2026-11-14 15:20 ` albin_yang
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=20261114092637.3206631-1-albin_yang@163.com \
--to=albin_yang@163.com \
--cc=albinwyang@tencent.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kayracizmeci@gmail.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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
all inboxes | Powered by JetHome®