linux-kernel - Re: [PATCH] sched/x86: Calculate booted cores after construction of sibling

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: <1338496257.28384.121.camel@twins>
Date:	Thu, 31 May 2012 22:30:57 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: [PATCH] sched/x86: Calculate booted cores after construction of
 sibling_mask

On Thu, 2012-05-31 at 13:07 +0530, Kamalesh Babulal wrote:
> While booting tip (1d06e6d354) on qemu with -smp sockets=1,cores=2,threads=2
> topology. There is a mismatch between the number of cores actually present
> and cores reported.
> 
> Changes related to calculating the number of booted cores was introduced
> by 316ad248307fb (sched/x86: Rewrite set_cpu_sibling_map()). With the
> clean up, the calculation of booted cores per package is done on an
> incompletely constructed sibling_mask per cpu.
> 
> sched/x86: Calculate booted cores after construction of sibling_mask

Why repeat this subject again?

> This patch re-introduces the old behaviour of constructing the complete
> sibling mask of the cpu, before calculating the number of cores booted.

> Signed-off-by: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
> ---
>  arch/x86/kernel/smpboot.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index fd019d7..a8d78f3 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -382,7 +382,12 @@ void __cpuinit set_cpu_sibling_map(int cpu)
>  		if ((i == cpu) || (has_mc && match_llc(c, o)))
>  			link_mask(llc_shared, cpu, i);
> 
> -		if ((i == cpu) || (has_mc && match_mc(c, o))) {
> +	}
> +
> +	for_each_cpu(i, cpu_sibling_setup_mask) {
> +		o = &cpu_data(i);
> +
> +	if ((i == cpu) || (has_mc && match_mc(c, o))) {
>  			link_mask(core, cpu, i);
> 
>  			/*

This patch actually horribly mangles the indenting. I did the below to
it:


---
Subject: sched/x86: Calculate booted cores after construction of sibling_mask
From: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Date: Thu, 31 May 2012 13:07:38 +0530

Commit 316ad248307fb ("sched/x86: Rewrite set_cpu_sibling_map()")
broke the booted_cores accounting.

The problem is that the booted_cores accounting needs all the
sibling links set up. So restore the second loop and add a comment as
to why its needed.

On qemu booted with -smp sockets=1,cores=2,threads=2;
Before:
$ grep cores /proc/cpuinfo
cpu cores       : 2
cpu cores       : 1
cpu cores       : 4
cpu cores       : 3

With the patch:
$ grep cores /proc/cpuinfo
cpu cores       : 2
cpu cores       : 2
cpu cores       : 2
cpu cores       : 2

Signed-off-by: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Link: http://lkml.kernel.org/r/20120531073738.GH7511@linux.vnet.ibm.com
---
 arch/x86/kernel/smpboot.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -382,6 +382,15 @@ void __cpuinit set_cpu_sibling_map(int c
 		if ((i == cpu) || (has_mc && match_llc(c, o)))
 			link_mask(llc_shared, cpu, i);
 
+	}
+
+	/*
+	 * This needs a separate iteration over the cpus because we rely on all
+	 * cpu_sibling_mask links to be set-up.
+	 */
+	for_each_cpu(i, cpu_sibling_setup_mask) {
+		o = &cpu_data(i);
+
 		if ((i == cpu) || (has_mc && match_mc(c, o))) {
 			link_mask(core, cpu, i);
 

--
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/