public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Herrmann <aherrmann@suse.com>
To: Borislav Petkov <bp@suse.de>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, peterz@infradead.org,
	Yazen.Ghannam@amd.com
Subject: Re: [PATCH v4 2/2] x86/amd: Fixup cpu_core_id for family17h downcore configuration
Date: Fri, 28 Jul 2017 11:39:43 +0200	[thread overview]
Message-ID: <20170728093943.GA1967@suselix> (raw)
In-Reply-To: <20170724144445.GA31300@nazgul.tnic>

On Mon, Jul 24, 2017 at 04:44:45PM +0200, Borislav Petkov wrote:
> On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> > Actually, this is not totally accurate. My apology. This patch is
> > mainly fix to incorrect core ID in /proc/cpuinfo.
> 
> So you're "fixing" only some numbering thing. Because core_id doesn't
> have any influence on anything. Here's on an Intel box I have here:
> 
> processor :  0		 physical id : 0	 core id : 0
> processor :  1		 physical id : 1	 core id : 0

  ---8<---

> processor : 62		 physical id : 2	 core id : 11
> processor : 63		 physical id : 3	 core id : 11
> 
> So those core id numbers can be anything as long as the cpumasks used by
> the scheduler are correct.

And as long as the user is able to find consistent topology
information.  (Ie. via /proc/cpuinfo and/or
/sys/bus/cpu/devices/cpuX/topology/)

> > This is due to the cpu_core_id fixup in amd_get_topology() below:
> > 
> >         /* fixup multi-node processor information */
> >         if (nodes_per_socket > 1) {
> >                 u32 cus_per_node;
> > 
> >                 set_cpu_cap(c, X86_FEATURE_AMD_DCM);
> >                 cus_per_node = c->x86_max_cores / nodes_per_socket;
> > 
> >                 /* core id has to be in the [0 .. cores_per_node - 1] range */
> >                 c->cpu_core_id %= cus_per_node;
> >         }
> 
> AFAICT, Andreas did this for MC at the time:
> 
> 4a376ec3a259 ("x86: Fix CPU llc_shared_map information for AMD Magny-Cours")
> 
> but I don't think we need to care about core_ids fitting into the node
> range anymore. For the above reason - topology doesn't use core ids.

IIRC this was the way to fix llc_shared_map as CPUID functions could
not be used to figure which cores belong to the same compute unit.

> So you can just as well let ->cpu_core_id be derived from the
> ->initial_apicid as it is being done now in amd_detect_cmp().
> 
> In order not to cause any more confusion, you can limit the above fixup
> to anything below F17h so that we don't upset existing users and add a
> big fat comment as to why we're doing this. But if it is only a silly
> numbering thing, I don't see the need for doing that jumping through
> hoops.
> 
> -- 
> Regards/Gruss,
>     Boris.

Regards,

Andreas

      parent reply	other threads:[~2017-07-28  9:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24  9:22 [PATCH v4 0/2] x86/amd: Refactor and fixup family17h cpu_core_id Suravee Suthikulpanit
2017-07-24  9:22 ` [PATCH v4 1/2] x86/amd: Refactor topology extension related code Suravee Suthikulpanit
2017-07-24  9:22 ` [PATCH v4 2/2] x86/amd: Fixup cpu_core_id for family17h downcore configuration Suravee Suthikulpanit
2017-07-24 11:14   ` Borislav Petkov
2017-07-24 14:14     ` Suravee Suthikulpanit
2017-07-24 14:44       ` Borislav Petkov
2017-07-25  5:51         ` Suravee Suthikulpanit
2017-07-25  5:56           ` Borislav Petkov
2017-07-25  6:02             ` Suravee Suthikulpanit
2017-07-25  8:07               ` Borislav Petkov
2017-07-28  9:39         ` Andreas Herrmann [this message]

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=20170728093943.GA1967@suselix \
    --to=aherrmann@suse.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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