All of lore.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, 3 Jan 2017 11:49:38 +0100	[thread overview]
Message-ID: <586B81C2.3050108@inria.fr> (raw)
In-Reply-To: <583DECC8.4000507@inria.fr>



Le 29/11/2016 22:02, Brice Goglin a écrit :
> 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>

Hello Borislav
Are you pushing this fix to Linus soon?
We received several bug reports on our side about dual-core compute
units being exposed as a dual-threaded single-cores in sysfs.
Thanks
Brice




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

  parent reply	other threads:[~2017-01-03 10:49 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
2016-11-29 21:15     ` Borislav Petkov
2017-01-03 10:49     ` Brice Goglin [this message]
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=586B81C2.3050108@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 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.