All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	x86@kernel.org
Subject: Re: [tip: sched/core] sched/debug: Change SCHED_WARN_ON() to WARN_ON_ONCE()
Date: Tue, 25 Mar 2025 10:37:20 +0100	[thread overview]
Message-ID: <Z-J5UEFwM3gh6VXR@gmail.com> (raw)
In-Reply-To: <20250324115955.GF14944@noisy.programming.kicks-ass.net>


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

> On Thu, Mar 20, 2025 at 09:00:05AM -0000, tip-bot2 for Ingo Molnar wrote:
> > The following commit has been merged into the sched/core branch of tip:
> > 
> > Commit-ID:     f7d2728cc032a23fccb5ecde69793a38eb30ba5c
> > Gitweb:        https://git.kernel.org/tip/f7d2728cc032a23fccb5ecde69793a38eb30ba5c
> > Author:        Ingo Molnar <mingo@kernel.org>
> > AuthorDate:    Mon, 17 Mar 2025 11:42:52 +01:00
> > Committer:     Ingo Molnar <mingo@kernel.org>
> > CommitterDate: Wed, 19 Mar 2025 22:20:53 +01:00
> > 
> > sched/debug: Change SCHED_WARN_ON() to WARN_ON_ONCE()
> > 
> > The scheduler has this special SCHED_WARN() facility that
> > depends on CONFIG_SCHED_DEBUG.
> > 
> > Since CONFIG_SCHED_DEBUG is getting removed, convert
> > SCHED_WARN() to WARN_ON_ONCE().
> > 
> > Note that the warning output isn't 100% equivalent:
> > 
> >    #define SCHED_WARN_ON(x)      WARN_ONCE(x, #x)
> > 
> > Because SCHED_WARN_ON() would output the 'x' condition
> > as well, while WARN_ONCE() will only show a backtrace.
> > 
> > Hopefully these are rare enough to not really matter.
> > 
> > If it does, we should probably introduce a new WARN_ON()
> > variant that outputs the condition in stringified form,
> > or improve WARN_ON() itself.
> 
> So those strings really were useful, trouble is WARN_ONCE() generates
> utter crap code compared to WARN_ON_ONCE(), but since SCHED_DEBUG that
> doesn't really matter.

Why wouldn't it matter? CONFIG_SCHED_DEBUG was turned on for 99.9999% 
of Linux users, ie. we generated crap code for most of our users.

And as a side effect of using the standard WARN_ON_ONCE() primitive we 
now generate better code, at the expense of harder to interpret debug 
output, right?

Ie. CONFIG_SCHED_DEBUG has obfuscated crappy code generation under the 
"it's only debugging code" pretense, right?

> Also, last time I measured, there was a measurable performance
> difference between SCHED_DEBUG=n and SCHED_DEBUG=y.

Which 99.9999% of Linux users are affected by. The config option 
basically did nothing for them but hide this overhead...

Thanks,

	Ingo

  reply	other threads:[~2025-03-25  9:37 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 [this message]
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
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=Z-J5UEFwM3gh6VXR@gmail.com \
    --to=mingo@kernel.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.org \
    /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.