public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brice Goglin <Brice.Goglin@inria.fr>
To: Borislav Petkov <bp@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: AMD Bulldozer topology regression since 4.6
Date: Tue, 29 Nov 2016 22:02:00 +0100	[thread overview]
Message-ID: <583DECC8.4000507@inria.fr> (raw)
In-Reply-To: <20161129193923.x2i6hctkdwalzfn5@pd.tnic>

Le 29/11/2016 20:39, Borislav Petkov a écrit :
> Does that fix it?
>
> Patch is against latest tip/master because we have some more changes in
> that area.

I tested the second patch on top of 4.8.11, it brings core_id back to
where it was before 4.6, thanks.

Reported-and-tested-by: Brice Goglin <Brice.Goglin@inria.fr>

However thread_siblings isn't back to where it was in 4.5. Now we have a
single bit in each thread_siblings mask. That's correct with respect to
the sysfs topology documentation. In 4.5, there were two bits (one for
each core of the compute unit), which was wrong (cores with different
core_ids shouldn't appear in each other thread_siblings). I assumed that
these processors had to break the sysfs topology documentation to expose
the concept of "dual-core compute-unit" which somehow sits between
hyperthreading and dual-core.

I personally do not care much about this regression, not sure about
other user-space tools?

Another minor related change: /proc/cpuinfo shows "cpu cores : 16"
instead of "8".

Brice


>
> ---
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 4daad1e39352..a070d7b0a133 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -305,15 +305,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>  
>  	/* get information required for multi-node processors */
>  	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
> -		u32 eax, ebx, ecx, edx;
> -
> -		cpuid(0x8000001e, &eax, &ebx, &ecx, &edx);
> -		node_id = ecx & 7;
> -
> -		/* get compute unit information */
> -		smp_num_siblings = ((ebx >> 8) & 3) + 1;
> -		c->x86_max_cores /= smp_num_siblings;
> -		c->cpu_core_id = ebx & 0xff;
> +		node_id = cpuid_ecx(0x8000001e) & 7;
>  
>  		/*
>  		 * We may have multiple LLCs if L3 caches exist, so check if we
> ---
>
> Just in case, I have one against Linus' master too:
>
> ---
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 1e81a37c034e..19f50a9d6b42 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -305,15 +305,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>  
>  	/* get information required for multi-node processors */
>  	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
> -		u32 eax, ebx, ecx, edx;
> -
> -		cpuid(0x8000001e, &eax, &ebx, &ecx, &edx);
> -		node_id = ecx & 7;
> -
> -		/* get compute unit information */
> -		smp_num_siblings = ((ebx >> 8) & 3) + 1;
> -		c->x86_max_cores /= smp_num_siblings;
> -		c->cpu_core_id = ebx & 0xff;
> +		node_id = cpuid_ecx(0x8000001e) & 7;
>  	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
>  		u64 value;
> ---
>

  reply	other threads:[~2016-11-29 21:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29  7:03 AMD Bulldozer topology regression since 4.6 Brice Goglin
2016-11-29 19:39 ` Borislav Petkov
2016-11-29 21:02   ` Brice Goglin [this message]
2016-11-29 21:15     ` Borislav Petkov
2017-01-03 10:49     ` Brice Goglin
2017-01-03 13:22       ` Borislav Petkov

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=583DECC8.4000507@inria.fr \
    --to=brice.goglin@inria.fr \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox