All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mel Gorman <mgorman@suse.de>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH 0/5] sched: Make CONFIG_SCHED_DEBUG features unconditional
Date: Wed, 19 Mar 2025 22:09:49 +0100	[thread overview]
Message-ID: <Z9syncxlUbb_oj4Q@gmail.com> (raw)
In-Reply-To: <xhsmh4izppfqw.mognet@vschneid-thinkpadt14sgen2i.remote.csb>


* Valentin Schneider <vschneid@redhat.com> wrote:

> On 17/03/25 11:42, Ingo Molnar wrote:
> > For more than a decade, CONFIG_SCHED_DEBUG=y has been enabled
> > in all the major Linux distributions:
> >
> >    /boot/config-6.11.0-19-generic:CONFIG_SCHED_DEBUG=y
> >
> > The reason is that while originally CONFIG_SCHED_DEBUG started
> > out as a debugging feature, over the years (decades ...) it has
> > grown various bits of statistics, instrumentation and
> > control knobs that are useful for sysadmin and general software
> > development purposes as well.
> >
> > But within the kernel we still pretend that there's a choice,
> > and sometimes code that is seemingly 'debug only' creates overhead
> > that should be optimized in reality.
> >
> > So make it all official and make CONFIG_SCHED_DEBUG unconditional.
> > This gets rid of a large amount of #ifdefs, so good riddance ...
> >
> 
> Pretty much every distro I'm aware of has CONFIG_SCHED_DEBUG=y; a quick check
> tells me it's been like so for RHEL since at least 2013, and that's from a
> commit copying configs from RHEL-6 to RHEL-7.
> 
> Two things however come to mind:
> 
> 1) What does this mean for the debug stuff we've repeatedly said wasn't ABI
>    because it was under CONFIG_SCHED_DEBUG? I've been burned by making
>    sched_domain.flags read-only, and there's still writable stuff:
> 
>    # ls -al /sys/kernel/debug/sched/domains/cpu0/domain0/
>    total 0
>    drwxr-xr-x. 2 root root 0 Mar 19 04:36 .
>    drwxr-xr-x. 3 root root 0 Mar 19 04:36 ..
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 busy_factor
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 cache_nice_tries
>    -r--r--r--. 1 root root 0 Mar 19 04:36 flags
>    -r--r--r--. 1 root root 0 Mar 19 04:36 groups_flags
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 imbalance_pct
>    -r--r--r--. 1 root root 0 Mar 19 04:36 level
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 max_interval
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 max_newidle_lb_cost
>    -rw-r--r--. 1 root root 0 Mar 19 04:36 min_interval
>    -r--r--r--. 1 root root 0 Mar 19 04:36 name
> 
>    + all the non topology related debug knobs.

Yeah, I don't think these or other sysctls are as contentious as 
previously thought. We might want to put '/debug/' into the directory 
name above, or we could move it over to debugfs entirely - but we 
should make it clear via the name that these are debugging knobs in 
essence.

> 2) Peter mentioned a few times that, last time it was benchmarked, there
>    were noticeable perf differences between CONFIG_SCHED_DEBUG=n and
>    CONFIG_SCHED_DEBUG=y. This would be an occasion to re-measure that and
>    potentially move (some of) these checks to e.g. a sched_debug_verbose
>    static key.

Yeah, and this is an argument strongly *in favor* of eliminating 
CONFIG_SCHED_DEBUG: in a way the CONFIG_SCHED_DEBUG "option" created a 
false sense of "it's only debug code". But it's not a genuine debug 
option, it's actual overhead for the vast majority of Linux distros and 
users.

So let's just eliminate SCHED_DEBUG, and fix any overhead. It's exactly 
what we should do anyway - nothing changes IMHO, just the appearance of 
urgency. :-)

Thanks,

	Ingo

  reply	other threads:[~2025-03-19 21:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 10:42 [PATCH 0/5] sched: Make CONFIG_SCHED_DEBUG features unconditional Ingo Molnar
2025-03-17 10:42 ` [PATCH 1/5] sched/debug: Change SCHED_WARN_ON() to WARN_ON_ONCE() Ingo Molnar
2025-03-20  9:00   ` [tip: sched/core] " tip-bot2 for Ingo Molnar
2025-03-24 11:59     ` Peter Zijlstra
2025-03-25  9:37       ` Ingo Molnar
2025-03-25 11:18         ` [PATCH] bug: Introduce CONFIG_DEBUG_BUGVERBOSE_EXTRA=y to also log warning conditions Ingo Molnar
2025-03-25 12:36           ` Peter Zijlstra
2025-03-25 17:48             ` Linus Torvalds
2025-03-25 18:46               ` Peter Zijlstra
2025-03-25 22:42               ` [PATCH] bug: Add the condition string to the CONFIG_DEBUG_BUGVERBOSE=y output Ingo Molnar
2025-03-25 23:12                 ` Linus Torvalds
2025-03-26  7:42                   ` Ingo Molnar
2025-03-17 10:42 ` [PATCH 2/5] sched/debug: Make 'const_debug' tunables unconditional __read_mostly Ingo Molnar
2025-03-20  9:00   ` [tip: sched/core] " tip-bot2 for Ingo Molnar
2025-03-17 10:42 ` [PATCH 3/5] sched/debug: Make CONFIG_SCHED_DEBUG functionality unconditional Ingo Molnar
2025-03-20  9:00   ` [tip: sched/core] " tip-bot2 for Ingo Molnar
2025-03-17 10:42 ` [PATCH 4/5] sched/debug, Documentation: Remove (most) CONFIG_SCHED_DEBUG references from documentation Ingo Molnar
2025-03-20  9:00   ` [tip: sched/core] " tip-bot2 for Ingo Molnar
2025-03-17 10:42 ` [PATCH 5/5] sched/debug: Remove CONFIG_SCHED_DEBUG Ingo Molnar
2025-03-20  8:59   ` [tip: sched/core] " tip-bot2 for Ingo Molnar
2025-03-24 11:57     ` Peter Zijlstra
2025-03-17 21:39 ` [PATCH 0/5] sched: Make CONFIG_SCHED_DEBUG features unconditional Linus Torvalds
2025-03-17 22:24   ` Ingo Molnar
2025-03-17 22:42     ` Ingo Molnar
2025-03-19  8:49 ` Valentin Schneider
2025-03-19 21:09   ` Ingo Molnar [this message]
2025-03-19 12:48 ` Shrikanth Hegde
2025-03-19 21:14   ` Ingo Molnar
2025-03-20  4:41     ` Shrikanth Hegde
2025-03-20  9:00     ` [tip: sched/core] sched/debug: Remove CONFIG_SCHED_DEBUG from self-test config files tip-bot2 for Ingo Molnar

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=Z9syncxlUbb_oj4Q@gmail.com \
    --to=mingo@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --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.