nr_spread_over tracks the number of instances where the difference
between a scheduling entity's virtual runtime and the minimum virtual
runtime in the runqueue exceeds three times the scheduler latency,
indicating significant disparity in task scheduling.
Commit 5e963f2bd465 ("sched/fair: Commit to EEVDF") removed its usage.

cfs_rq->exec_clock was used to account for time spent executing tasks.
Commit 5d69eca542ee ("sched: Unify runtime accounting across classes")
removed its usage.

cfs_rq::nr_spread_over and cfs_rq::exec_clock are not used anymore in
eevdf. Remove them from struct cfs_rq.

Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
Acked-by: Vishal Chourasia <vishalc@linux.ibm.com>
Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
Changes in v3:
Fix the commit description style suggested by Prateek.

Changes in v2:
Add more description of nr_spread_over and exec_clock
suggested by Vishal.
---
 kernel/sched/debug.c | 4 ----
 kernel/sched/sched.h | 6 ------
 2 files changed, 10 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index c1eb9a1afd13..90c4a9998377 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -641,8 +641,6 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
 	SEQ_printf(m, "\n");
 	SEQ_printf(m, "cfs_rq[%d]:\n", cpu);
 #endif
-	SEQ_printf(m, "  .%-30s: %Ld.%06ld\n", "exec_clock",
-			SPLIT_NS(cfs_rq->exec_clock));
 
 	raw_spin_rq_lock_irqsave(rq, flags);
 	root = __pick_root_entity(cfs_rq);
@@ -669,8 +667,6 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
 			SPLIT_NS(right_vruntime));
 	spread = right_vruntime - left_vruntime;
 	SEQ_printf(m, "  .%-30s: %Ld.%06ld\n", "spread", SPLIT_NS(spread));
-	SEQ_printf(m, "  .%-30s: %d\n", "nr_spread_over",
-			cfs_rq->nr_spread_over);
 	SEQ_printf(m, "  .%-30s: %d\n", "nr_running", cfs_rq->nr_running);
 	SEQ_printf(m, "  .%-30s: %d\n", "h_nr_running", cfs_rq->h_nr_running);
 	SEQ_printf(m, "  .%-30s: %d\n", "idle_nr_running",
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4c36cc680361..8a071022bdec 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -599,7 +599,6 @@ struct cfs_rq {
 	s64			avg_vruntime;
 	u64			avg_load;
 
-	u64			exec_clock;
 	u64			min_vruntime;
 #ifdef CONFIG_SCHED_CORE
 	unsigned int		forceidle_seq;
@@ -619,10 +618,6 @@ struct cfs_rq {
 	struct sched_entity	*curr;
 	struct sched_entity	*next;
 
-#ifdef	CONFIG_SCHED_DEBUG
-	unsigned int		nr_spread_over;
-#endif
-
 #ifdef CONFIG_SMP
 	/*
 	 * CFS load tracking
@@ -1158,7 +1153,6 @@ struct rq {
 	/* latency stats */
 	struct sched_info	rq_sched_info;
 	unsigned long long	rq_cpu_time;
-	/* could above be rq->cfs_rq.exec_clock + rq->rt_rq.rt_runtime ? */
 
 	/* sys_sched_yield() stats */
 	unsigned int		yld_count;
-- 
2.20.1

On 20/07/2024 05:19, Chuyi Zhou wrote:
> nr_spread_over tracks the number of instances where the difference
> between a scheduling entity's virtual runtime and the minimum virtual
> runtime in the runqueue exceeds three times the scheduler latency,
> indicating significant disparity in task scheduling.
> Commit 5e963f2bd465 ("sched/fair: Commit to EEVDF") removed its usage.
> 
> cfs_rq->exec_clock was used to account for time spent executing tasks.
> Commit 5d69eca542ee ("sched: Unify runtime accounting across classes")
> removed its usage.

I was under the impression this commit removed
'schedstat_add(cfs_rq->exec_clock, delta_exec)' from update_curr() by
mistake?

That's why I sent out this patch back in May:

https://lkml.kernel.org/r/20240503104605.1871571-1-dietmar.eggemann@arm.com

to add it back.

On Tue, Jul 23, 2024 at 10:47:22PM +0200, Dietmar Eggemann wrote:
> On 20/07/2024 05:19, Chuyi Zhou wrote:
> > nr_spread_over tracks the number of instances where the difference
> > between a scheduling entity's virtual runtime and the minimum virtual
> > runtime in the runqueue exceeds three times the scheduler latency,
> > indicating significant disparity in task scheduling.
> > Commit 5e963f2bd465 ("sched/fair: Commit to EEVDF") removed its usage.
> > 
> > cfs_rq->exec_clock was used to account for time spent executing tasks.
> > Commit 5d69eca542ee ("sched: Unify runtime accounting across classes")
> > removed its usage.
> 
> I was under the impression this commit removed
> 'schedstat_add(cfs_rq->exec_clock, delta_exec)' from update_curr() by
> mistake?
> 
> That's why I sent out this patch back in May:
> 
> https://lkml.kernel.org/r/20240503104605.1871571-1-dietmar.eggemann@arm.com
> 
> to add it back.

Probably an accident yes. Is that exec_clock thing useful though? I
mean, I don't much care either way around.

I had a previous version of this patched lined up, but its easy enough
to press 'dd' on it.

On 24/07/2024 10:01, Peter Zijlstra wrote:
> On Tue, Jul 23, 2024 at 10:47:22PM +0200, Dietmar Eggemann wrote:
>> On 20/07/2024 05:19, Chuyi Zhou wrote:
>>> nr_spread_over tracks the number of instances where the difference
>>> between a scheduling entity's virtual runtime and the minimum virtual
>>> runtime in the runqueue exceeds three times the scheduler latency,
>>> indicating significant disparity in task scheduling.
>>> Commit 5e963f2bd465 ("sched/fair: Commit to EEVDF") removed its usage.
>>>
>>> cfs_rq->exec_clock was used to account for time spent executing tasks.
>>> Commit 5d69eca542ee ("sched: Unify runtime accounting across classes")
>>> removed its usage.
>>
>> I was under the impression this commit removed
>> 'schedstat_add(cfs_rq->exec_clock, delta_exec)' from update_curr() by
>> mistake?
>>
>> That's why I sent out this patch back in May:
>>
>> https://lkml.kernel.org/r/20240503104605.1871571-1-dietmar.eggemann@arm.com
>>
>> to add it back.
> 
> Probably an accident yes. Is that exec_clock thing useful though? I
> mean, I don't much care either way around.
> 
> I had a previous version of this patched lined up, but its easy enough
> to press 'dd' on it.

Not terrible useful I suppose. I had one testcase where I thought it
would be useful to compare those numbers back in May. This was the time
when I realized that .exec_clock stays 0.

But this was the only time I used it. So I'm fine with removing it. Our
ultimate goal should be anyway to reduce the amount of this mildly
useful stuff in this area.