linux-kernel - Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

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]

Message-ID: <20140722140912.GA23406@wolff.to>
Date:	Tue, 22 Jul 2014 09:09:12 -0500
From:	Bruno Wolff III <bruno@...ff.to>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Dietmar Eggemann <dietmar.eggemann@....com>,
	Josh Boyer <jwboyer@...hat.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Scheduler regression from
 caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 15:35:14 +0200,
  Peter Zijlstra <peterz@...radead.org> wrote:
>On Tue, Jul 22, 2014 at 03:26:03PM +0200, Peter Zijlstra wrote:
>
>Something like so.. anything obviously broken?

Do you want me to test this change instead of, or combined with the other 
patch you wanted tested earlier?

>
>---
> arch/x86/kernel/cpu/intel.c           | 22 +++++++++++-----------
> arch/x86/kernel/cpu/intel_cacheinfo.c | 12 ++++++++++++
> 2 files changed, 23 insertions(+), 11 deletions(-)
>
>diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
>index 0fd955778f35..9483ee5b3991 100644
>--- a/arch/x86/kernel/cpu/intel.c
>+++ b/arch/x86/kernel/cpu/intel.c
>@@ -370,6 +370,17 @@ static void init_intel(struct cpuinfo_x86 *c)
> 	 */
> 	detect_extended_topology(c);
>
>+	if (!cpu_has(c, X86_FEATURE_XTOPOLOGY)) {
>+		/*
>+		 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
>+		 * detection.
>+		 */
>+		c->x86_max_cores = intel_num_cpu_cores(c);
>+#ifdef CONFIG_X86_32
>+		detect_ht(c);
>+#endif
>+	}
>+
> 	l2 = init_intel_cacheinfo(c);
> 	if (c->cpuid_level > 9) {
> 		unsigned eax = cpuid_eax(10);
>@@ -438,17 +449,6 @@ static void init_intel(struct cpuinfo_x86 *c)
> 		set_cpu_cap(c, X86_FEATURE_P3);
> #endif
>
>-	if (!cpu_has(c, X86_FEATURE_XTOPOLOGY)) {
>-		/*
>-		 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
>-		 * detection.
>-		 */
>-		c->x86_max_cores = intel_num_cpu_cores(c);
>-#ifdef CONFIG_X86_32
>-		detect_ht(c);
>-#endif
>-	}
>-
> 	/* Work around errata */
> 	srat_detect_node(c);
>
>diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c b/arch/x86/kernel/cpu/intel_cacheinfo.c
>index a952e9c85b6f..9c8f7394c612 100644
>--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
>+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
>@@ -730,6 +730,18 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
> #endif
> 	}
>
>+#ifdef CONFIG_X86_HT
>+	/*
>+	 * If cpu_llc_id is not yet set, this means cpuid_level < 4 which in
>+	 * turns means that the only possibility is SMT (as indicated in
>+	 * cpuid1). Since cpuid2 doesn't specify shared caches, and we know
>+	 * that SMT shares all caches, we can unconditionally set cpu_llc_id to
>+	 * c->phys_proc_id.
>+	 */
>+	if (per_cpu(cpu_llc_id, cpu) == BAD_APICID)
>+		per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
>+#endif
>+
> 	c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
>
> 	return l2;
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/