linux-kernel - [PATCH, -v2] sched/core: Disable CONFIG_SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Jun 2021 22:46:39 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH, -v2] sched/core: Disable CONFIG_SCHED_CORE by default


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Jun 28, 2021 at 12:57 PM Ingo Molnar <mingo@...nel.org> wrote:
> >
> > You are completely right, I missed this. Find below the patch to fix it -
> 
> I think you should update the helptext too, which currently says that
> it's enabled if SCHED_SMT is enabled.
> 
> And yes, it may be that there is no measurable performance downside,
> but this feature has been discussed and under development for a long
> time now, and I'd like the default to try to limit the impact since it
> makes little sense to most people.

Updated patch attached, which updates the help text and clarifies what 
overhead there is.

While the worst of the overhead is behind the __sched_core_enabled static 
key, there's a notable increase in pick_next_task(), which might be 
measurable with the right microbenchmark.

So the 'no overhead' claim is probably not entirely true, and comes from 
the context of *horrible* overhead of early iterations of the core 
scheduling feature ...

Thanks,

	Ingo

===================================>
From: Ingo Molnar <mingo@...nel.org>
Date: Mon, 28 Jun 2021 21:55:16 +0200
Subject: [PATCH] sched/core: Disable CONFIG_SCHED_CORE by default

This option at minimum adds extra code to the scheduler - even if
it's default unused - and most users wouldn't want it.

Reported-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 kernel/Kconfig.preempt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index bd7c4147b9a8..5876e30c5740 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -102,7 +102,6 @@ config PREEMPT_DYNAMIC
 
 config SCHED_CORE
 	bool "Core Scheduling for SMT"
-	default y
 	depends on SCHED_SMT
 	help
 	  This option permits Core Scheduling, a means of coordinated task
@@ -115,7 +114,8 @@ config SCHED_CORE
 	   - mitigation of some (not all) SMT side channels;
 	   - limiting SMT interference to improve determinism and/or performance.
 
-	  SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
-	  unused there should be no impact on performance.
+	  SCHED_CORE is default disabled. When it is enabled and unused,
+	  which is the likely usage by Linux distributions, there should
+	  be no measurable impact on performance.