From: "tip-bot2 for Zhan Xusheng" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Zhan Xusheng <zhanxusheng@xiaomi.com>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: sched/urgent] sched/fair: Fix stale comments referring to removed CFS concepts
Date: Mon, 29 Jun 2026 11:13:14 -0000 [thread overview]
Message-ID: <178273159419.3843924.17455384806679869461.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20260629030200.3165589-1-zhanxusheng@xiaomi.com>
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 17fdabfa3aeca3d07846a8d56ac0abf61b58bffd
Gitweb: https://git.kernel.org/tip/17fdabfa3aeca3d07846a8d56ac0abf61b58bffd
Author: Zhan Xusheng <zhanxusheng1024@gmail.com>
AuthorDate: Mon, 29 Jun 2026 11:02:00 +08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Mon, 29 Jun 2026 13:11:52 +02:00
sched/fair: Fix stale comments referring to removed CFS concepts
A few comments still describe the pre-EEVDF CFS world:
- sysctl_sched_base_slice is documented as "Minimal preemption
granularity for CPU-bound tasks". That was the wording of the old
sysctl_sched_min_granularity, renamed in commit e4ec3318a17f
("sched/debug: Rename sysctl_sched_min_granularity to
sysctl_sched_base_slice"). Under EEVDF it is the default base time
slice / request size (r_i) used to compute the virtual deadline, as
documented in update_deadline().
- Two comments still mention sched_slice(), which was removed when the
fair class committed to EEVDF in commit 5e963f2bd465 ("sched/fair:
Commit to EEVDF"). The dequeue-path comment should simply refer to
the task's slice (se->slice); the forced-idle comment describes the
slice accounting now performed by __entity_slice_used(), which is the
function actually used right below it.
No functional changes.
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20260629030200.3165589-1-zhanxusheng@xiaomi.com
---
kernel/sched/fair.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d78467e..599ff23 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -72,7 +72,10 @@
unsigned int sysctl_sched_tunable_scaling = SCHED_TUNABLESCALING_LOG;
/*
- * Minimal preemption granularity for CPU-bound tasks:
+ * Default base time slice (request size r_i) for SCHED_NORMAL/SCHED_BATCH:
+ *
+ * Under EEVDF this is the request size used to compute the virtual
+ * deadline; see update_deadline().
*
* (default: 0.70 msec * (1 + ilog(ncpus)), units: nanoseconds)
*/
@@ -7974,7 +7977,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags)
se = parent_entity(se);
/*
* Bias pick_next to pick a task from this cfs_rq, as
- * p is sleeping when it is within its sched_slice.
+ * p is sleeping when it is within its slice.
*/
if (task_sleep && se)
set_next_buddy(se);
@@ -14571,7 +14574,7 @@ static inline void task_tick_core(struct rq *rq, struct task_struct *curr)
* if the sibling is forced idle, then trigger schedule to
* give forced idle task a chance.
*
- * sched_slice() considers only this active rq and it gets the
+ * __entity_slice_used() considers only this active rq and it gets the
* whole slice. But during force idle, we have siblings acting
* like a single runqueue and hence we need to consider runnable
* tasks on this CPU and the forced idle CPU. Ideally, we should
next prev parent reply other threads:[~2026-06-29 11:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 3:02 [PATCH] " Zhan Xusheng
2026-06-29 11:13 ` tip-bot2 for Zhan Xusheng [this message]
2026-06-30 9:10 ` [tip: sched/urgent] " Peter Zijlstra
2026-06-30 11:33 ` Ingo Molnar
2026-06-30 11:32 ` [tip: sched/core] " tip-bot2 for Zhan Xusheng
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=178273159419.3843924.17455384806679869461.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
--cc=zhanxusheng@xiaomi.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®