All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Valentin Schneider <vschneid@redhat.com>
Subject: Re: [PATCH 2/9] sched/balancing: Remove reliance on 'enum cpu_idle_type' ordering when iterating [CPU_MAX_IDLE_TYPES] arrays in show_schedstat()
Date: Fri, 8 Mar 2024 10:55:48 +0100	[thread overview]
Message-ID: <ZergpN1xpWIwPsbx@gmail.com> (raw)
In-Reply-To: <aa13842e-ab81-45e0-87d4-2b5360ff4782@linux.ibm.com>


* Shrikanth Hegde <sshegde@linux.ibm.com> wrote:

> 
> 
> On 3/4/24 3:18 PM, Ingo Molnar wrote:
> > From: Shrikanth Hegde <sshegde@linux.ibm.com>
> > 
> > Shrikanth Hegde reported that show_schedstat() output broke when
> > the ordering of the definitions in 'enum cpu_idle_type' is changed,
> > because show_schedstat() assumed that 'CPU_IDLE' is 0.
> >
> Hi Ingo. 
> Feel free to drop me from the changelog. 

Yeah - I made you the author of the commit, and indeed it should not refer 
to you in the third person. :-) Fixed.

> 
> > @@ -150,8 +150,7 @@ static int show_schedstat(struct seq_file *seq, void *v)
> >  
> >  			seq_printf(seq, "domain%d %*pb", dcount++,
> >  				   cpumask_pr_args(sched_domain_span(sd)));
> > -			for (itype = CPU_IDLE; itype < CPU_MAX_IDLE_TYPES;
> > -					itype++) {
> > +			for (itype = 0; itype < CPU_MAX_IDLE_TYPES; itype++) {
> 
> 
> It would still not be same order as current documentation of schedstat. 
> no? The documentation would need changes too. Change SCHEDSTAT_VERSION to 
> 16?

Correct. I've bumped SCHEDSTAT_VERSION up to 16 now, but since it hasn't 
been changed for the last 10+ years I'm wondering whether that's the right 
thing to do or we should add a quirk to maintain the v15 ordering?

I think we should also output the actual symbolic cpu_idle_type names into 
schedstat, so that tooling (and observant kernel developers) can see the 
actual ordering of the [CPU_MAX_IDLE_TYPES] columns.

A new line like this (mockup):

  cpu0 0 0 4400 1485 1624 1229 301472313236 120382198 7714    
+ cpu_idle_type CPU_IDLE 0 CPU_NOT_IDLE 1 CPU_NEWLY_IDLE 2 CPU_MAX_IDLE_TYPES 3
  domain0 00000000,00000000,00000055 1661 1661 0 0 0 0 0 1661 2495 2495 0 0 0 0 0 2495 67 66 1 2 0 0 0 66 0 0 0 0 0 0 0 0 0 133 38 0

... and after the change this would become:

  cpu_idle_type CPU_NOT_IDLE 0 CPU_IDLE 1 CPU_NEWLY_IDLE 2 CPU_MAX_IDLE_TYPES 3

or so?

This gives tooling (that cares) a way to enumerate the idle types, without 
having to rely on their numeric values. Adding a new line to schedstat 
shouldn't break existing tooling - and if it does, we've increased 
SCHEDSTAT_VERSION to 16 anyway. ;-)

Thanks,

	Ingo

  reply	other threads:[~2024-03-08  9:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04  9:48 [PATCH -v3 0/9] sched/balancing: Misc updates & cleanups Ingo Molnar
2024-03-04  9:48 ` [PATCH 1/9] sched/balancing: Switch the 'DEFINE_SPINLOCK(balancing)' spinlock into an 'atomic_t sched_balance_running' flag Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-08  9:48     ` Ingo Molnar
2024-03-05 11:11   ` Shrikanth Hegde
2024-03-08 11:23     ` Ingo Molnar
2024-03-08 14:48       ` Shrikanth Hegde
2024-03-12 10:57         ` Ingo Molnar
2024-03-21 12:12           ` Shrikanth Hegde
2024-03-04  9:48 ` [PATCH 2/9] sched/balancing: Remove reliance on 'enum cpu_idle_type' ordering when iterating [CPU_MAX_IDLE_TYPES] arrays in show_schedstat() Ingo Molnar
2024-03-04 15:05   ` Shrikanth Hegde
2024-03-08  9:55     ` Ingo Molnar [this message]
2024-03-04  9:48 ` [PATCH 3/9] sched/balancing: Change 'enum cpu_idle_type' to have more natural definitions Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-06 15:46   ` Vincent Guittot
2024-03-08  9:59     ` Ingo Molnar
2024-03-04  9:48 ` [PATCH 4/9] sched/balancing: Change comment formatting to not overlap Git conflict marker lines Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-06 15:44   ` Vincent Guittot
2024-03-04  9:48 ` [PATCH 5/9] sched/balancing: Fix comments (trying to) refer to NOHZ_BALANCE_KICK Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-06 15:43   ` Vincent Guittot
2024-03-08 10:11     ` Ingo Molnar
2024-03-04  9:48 ` [PATCH 6/9] sched/balancing: Update run_rebalance_domains() comments Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-06 16:17     ` Vincent Guittot
2024-03-08 10:15       ` Ingo Molnar
2024-03-08 11:57         ` Vincent Guittot
2024-03-08 16:45           ` Valentin Schneider
2024-03-04  9:48 ` [PATCH 7/9] sched/balancing: Vertically align the comments of 'struct sg_lb_stats' and 'struct sd_lb_stats' Ingo Molnar
2024-03-05 10:50   ` Valentin Schneider
2024-03-04  9:48 ` [PATCH 8/9] sched/balancing: Update comments in " Ingo Molnar
2024-03-05 10:51   ` Valentin Schneider
2024-03-04  9:48 ` [PATCH 9/9] sched/balancing: Rename run_rebalance_domains() => sched_balance_softirq() Ingo Molnar
2024-03-05 10:51   ` Valentin Schneider

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=ZergpN1xpWIwPsbx@gmail.com \
    --to=mingo@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=sshegde@linux.ibm.com \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.