Re: [PATCH 04/10] sched/debug: Increase SCHEDSTAT_VERSION to 16

[Gautham R. Shenoy]

Hello Ingo, Shrikanth,

On Tue, Mar 12, 2024 at 11:01:54AM +0100, Ingo Molnar wrote:
> 
> * Shrikanth Hegde <sshegde@xxxxxxxxxxxxx> wrote:
> 
> > 
> > 
> > On 3/8/24 4:28 PM, Ingo Molnar wrote:
> > > We changed the order of definitions within 'enum cpu_idle_type',
> > > which changed the order of [CPU_MAX_IDLE_TYPES] columns in
> > > show_schedstat().
> > > 
> > 
> > > +++ b/kernel/sched/stats.c
> > > @@ -113,7 +113,7 @@ void __update_stats_enqueue_sleeper(struct rq *rq, struct task_struct *p,
> > >   * Bump this up when changing the output format or the meaning of an existing
> > >   * format, so that tools can adapt (or abort)
> > >   */
> > > -#define SCHEDSTAT_VERSION 15
> > > +#define SCHEDSTAT_VERSION 16
> > 
> > Please add the info about version, and change of the order 
> > briefly in Documentation/scheduler/sched-stats.rst as well.
> 
> Good point, I've added this paragraph to sched-stats.rst:
> 
>  +Version 16 of schedstats changed the order of definitions within
>  +'enum cpu_idle_type', which changed the order of [CPU_MAX_IDLE_TYPES]
>  +columns in show_schedstat(). In particular the position of CPU_IDLE
>  +and __CPU_NOT_IDLE changed places. The size of the array is unchanged.

Thanks for this change!

Since we are considering bumping up the version for this change, it
might be good to get rid of "lb_imbalance" which is currently a sum of
all the different kinds of imbalances (due to load, utilization,
number of tasks, misfit tasks). This is not useful.

Swapnil had a patch to print the different imbalances, which will
change the number of fields. Can we include this change into v16 as
well?

Swapnil, could you please rebase your patch on tip/sched/core and post
it ?

> 
> > One recent user that I recollect is sched scoreboard. Version number should 
> > be able to help the users when they it is breaking their scripts. 
> >

> > +Gautham, Any thoughts?

Yes, the scoreboard looks at the version. If it doesn't understand a
version, it will not parse it.  It can be extended to understand the
new version, since that's only about adding a new json.

> 
> If it's really a problem, I suspect we could maintain the v15 order of 
> output.

I don't think moving to v16 is an issue.

> 
> Thanks,
> 
> 	Ingo

--
Thanks and Regards
gautham.