Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1692568 > unrolled thread

Re: [PATCH] x86/amd: Fixup cpu_core_id for family17h downcore configuration

Started byBorislav Petkov <bp@suse.de>
First post2017-07-20 10:40 +0200
Last post2017-07-20 10:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] x86/amd: Fixup cpu_core_id for family17h downcore  configuration Borislav Petkov <bp@suse.de> - 2017-07-20 10:40 +0200
    Re: [PATCH] x86/amd: Fixup cpu_core_id for family17h downcore  configuration Ingo Molnar <mingo@kernel.org> - 2017-07-20 10:50 +0200

#1692568 — Re: [PATCH] x86/amd: Fixup cpu_core_id for family17h downcore configuration

FromBorislav Petkov <bp@suse.de>
Date2017-07-20 10:40 +0200
SubjectRe: [PATCH] x86/amd: Fixup cpu_core_id for family17h downcore configuration
Message-ID<u5fa2-4Lf-39@gated-at.bofh.it>
On Thu, Jul 20, 2017 at 03:29:28AM -0500, Suravee Suthikulpanit wrote:
> For family17h, current cpu_core_id is directly taken from the value
> CPUID_Fn8000001E_EBX[7:0] (CoreId), which is the physical ID of the
> core within a die. However, on system with downcore configuration
> (where not all physical cores within a die are available),
> this could result in the case where cpu_core_id > (cores_per_node - 1).
> 
> Fix up the cpu_core_id by breaking down the bitfields of CoreId,
> and calculate relative ID using available topology information.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  arch/x86/kernel/cpu/amd.c | 61 ++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index bb5abe8..e7de105 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -310,38 +310,67 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>  
>  	/* get information required for multi-node processors */
>  	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {

Please carve this whole TOPOEXT-specific logic out, into a separate
function, say __get_topoext() or so, for better readability/easier
review.

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [next] | [standalone]


#1692575

FromIngo Molnar <mingo@kernel.org>
Date2017-07-20 10:50 +0200
Message-ID<u5fjI-4Py-13@gated-at.bofh.it>
In reply to#1692568
* Borislav Petkov <bp@suse.de> wrote:

> On Thu, Jul 20, 2017 at 03:29:28AM -0500, Suravee Suthikulpanit wrote:
> > For family17h, current cpu_core_id is directly taken from the value
> > CPUID_Fn8000001E_EBX[7:0] (CoreId), which is the physical ID of the
> > core within a die. However, on system with downcore configuration
> > (where not all physical cores within a die are available),
> > this could result in the case where cpu_core_id > (cores_per_node - 1).
> > 
> > Fix up the cpu_core_id by breaking down the bitfields of CoreId,
> > and calculate relative ID using available topology information.
> > 
> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> > ---
> >  arch/x86/kernel/cpu/amd.c | 61 ++++++++++++++++++++++++++++++++++-------------
> >  1 file changed, 45 insertions(+), 16 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index bb5abe8..e7de105 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -310,38 +310,67 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
> >  
> >  	/* get information required for multi-node processors */
> >  	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
> 
> Please carve this whole TOPOEXT-specific logic out, into a separate
> function, say __get_topoext() or so, for better readability/easier
> review.

Also please do the factoring out in a separate preparatory cleanup patch, so that 
we can see the two changes isolated.

Thanks,

	Ingo

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web