From: Zhang Rui <rui.zhang@intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-hwmon@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, corbet@lwn.net, fenghua.yu@intel.com,
jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com
Subject: Re: [PATCH 0/7] x86/topology: Improve CPUID.1F handling
Date: Sun, 14 Aug 2022 01:10:51 +0800 [thread overview]
Message-ID: <9a1063a26351f859376ffae747fa0c89d73bdbc4.camel@intel.com> (raw)
In-Reply-To: <YveAp8W3zZliQXrq@gmail.com>
Hi, Ingo,
Thanks for reviewing this patch series.
On Sat, 2022-08-13 at 12:44 +0200, Ingo Molnar wrote:
>
> * Zhang Rui <rui.zhang@intel.com> wrote:
>
> > On Intel AlderLake-N platforms where there are Ecores only, the
> > Ecore
> > Module topology is enumerated via CPUID.1F Module level, which has
> > not
> > been supported by Linux kernel yet.
> >
> > This exposes two issues in current CPUID.1F handling code.
> > 1. Linux interprets the Module id bits as package id and
> > erroneously
> > reports a multi module system as a multi-package system.
> > 2. Linux excludes the unknown Module id bits from the core_id, and
> > results
> > in duplicate core_id’s shown in a package after the first issue
> > solved.
> >
> > Plus that, a third problem is observed on Intel Hybrid ADL-S/P
> > platforms.
> > The return value of CPUID.1F SMT level EBX (number of siblings)
> > differs on
> > Pcore CPUs and Ecore CPUs, and results in inconsistent
> > smp_num_siblings
> > value based on the Pcore/Ecore CPU enumeration order. This could
> > bring
> > some potential issues although we have not observed any
> > functionalities
> > issues so far.
> >
> > Patch 1/7 and 2/7 fix the first two issues. And at the same time,
> > it
> > reveals a reality that the core_id could be sparse on platforms
> > with
> > CPUID.1F support.
> > Patch 3/7 improves coretemp driver code to be able to handle sparse
> > core
> > id, which is the only driver that uses core_id as array index and
> > run on
> > platforms with CPUID.1F support.
> >
> > Patch 4/7 to 7/7 propose a fix for the third problem and update the
> > related Documents.
>
> Yeah, so patch 3/7 probably needs to come first - otherwise there's a
> window for bisection breakage.
Sure, I will re-arrange this.
thanks,
rui
next prev parent reply other threads:[~2022-08-13 17:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 16:41 [PATCH 0/7] x86/topology: Improve CPUID.1F handling Zhang Rui
2022-08-12 16:41 ` [PATCH 1/7] x86/topology: Fix multiple packages shown on a single-package system Zhang Rui
2022-08-12 16:41 ` [PATCH 2/7] x86/topology: Fix duplicated core_id within a package Zhang Rui
2022-08-12 16:41 ` [PATCH 3/7] hwmon/coretemp: Handle large core id value Zhang Rui
2022-08-12 17:16 ` Guenter Roeck
2022-08-13 17:24 ` Zhang Rui
2022-08-13 10:48 ` Ingo Molnar
2022-08-13 17:07 ` Zhang Rui
2022-08-14 9:12 ` Ingo Molnar
2022-08-12 16:41 ` [PATCH 4/7] x86/topology: Fix max_siblings calculation Zhang Rui
2022-08-12 16:41 ` [PATCH 5/7] Documentation: x86: Update smp_num_siblings/x86_max_cores description Zhang Rui
2022-08-12 16:41 ` [PATCH 6/7] Documentation: x86: Remove obsolete x86_max_dies description Zhang Rui
2022-08-12 16:41 ` [PATCH 7/7] perf/x86/intel/P4: Fix smp_num_siblings usage Zhang Rui
2022-08-13 10:50 ` Ingo Molnar
2022-08-13 17:29 ` Zhang Rui
2022-08-15 9:11 ` Peter Zijlstra
2022-08-16 2:26 ` Zhang Rui
2022-08-16 8:26 ` Peter Zijlstra
2022-08-13 10:44 ` [PATCH 0/7] x86/topology: Improve CPUID.1F handling Ingo Molnar
2022-08-13 17:10 ` Zhang Rui [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-12 15:08 Zhang Rui
2022-08-12 15:12 ` Zhang Rui
2022-08-12 16:09 ` Guenter Roeck
2022-08-12 16:13 ` Zhang Rui
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=9a1063a26351f859376ffae747fa0c89d73bdbc4.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=jdelvare@suse.com \
--cc=len.brown@intel.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).