[PATCH] sched/fair: Fix stale comments referring to removed CFS concepts

[PATCH] sched/fair: Fix stale comments referring to removed CFS concepts

[Zhan Xusheng]

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 change.

Signed-off-by: Zhan Xusheng <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 d78467ec6ee1..599ff23f52d3 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
-- 
2.43.0

[tip: sched/urgent] sched/fair: Fix stale comments referring to removed CFS concepts

[tip-bot2 for Zhan Xusheng]

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

Re: [tip: sched/urgent] sched/fair: Fix stale comments referring to removed CFS concepts

[Peter Zijlstra]

On Mon, Jun 29, 2026 at 11:13:14AM -0000, tip-bot2 for Zhan Xusheng wrote:
> 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

This is comments, cannot be urgent. Also generates non-trivial conflicts
against the patches I just stuck in sched/core. So zapped this commit.

Re: [tip: sched/urgent] sched/fair: Fix stale comments referring to removed CFS concepts

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Link: https://patch.msgid.link/20260629030200.3165589-1-zhanxusheng@xiaomi.com
> 
> This is comments, cannot be urgent.

We sometimes make exception for documentation fixes, which this
in a way is, but only when it does not interfere with pending
changes.

Alas it *does* interfere:

> Also generates non-trivial conflicts
> against the patches I just stuck in sched/core. So zapped this commit.

Sounds good, and I've reapplied a conflict-resolved version on top:

  19b7bdc3a155 ("sched/fair: Fix stale comments referring to removed CFS concepts")

Thanks,

	Ingo

[tip: sched/core] sched/fair: Fix stale comments referring to removed CFS concepts

[tip-bot2 for Zhan Xusheng]

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     19b7bdc3a1550ab2550427c33395bec7caeaf72d
Gitweb:        https://git.kernel.org/tip/19b7bdc3a1550ab2550427c33395bec7caeaf72d
Author:        Zhan Xusheng <zhanxusheng1024@gmail.com>
AuthorDate:    Mon, 29 Jun 2026 11:02:00 +08:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Tue, 30 Jun 2026 13:30:23 +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.

[ mingo: Ported to a more recent scheduler base ]

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 | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ce05acf..fc6cd55 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -73,7 +73,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)
  */
@@ -14676,7 +14679,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