[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKm+vGmWn=U+MLW1TzxnpAFxAiJRimO=HMArNp3FX1HXYA@mail.gmail.com>
Date: Wed, 20 Feb 2019 01:10:04 -0500
From: Len Brown <lenb@...nel.org>
To: Like Xu <like.xu@...ux.intel.com>
Cc: X86 ML <x86@...nel.org>, linux-kernel@...r.kernel.org,
Len Brown <len.brown@...el.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH 03/11] x86 topology: Add CPUID.1F multi-die/package support
On Tue, Feb 19, 2019 at 9:59 PM Like Xu <like.xu@...ux.intel.com> wrote:
> > -/* leaf 0xb sub-leaf types */
> > +/* extended topology sub-leaf types */
> > #define INVALID_TYPE 0
> > #define SMT_TYPE 1
> > #define CORE_TYPE 2
> > +#define DIE_TYPE 5
>
> This patch set is going to export die topology via sysfs
> while the extended topology sub-leaf type could be one of followings:
> SMT/Core/Module/Tile/Die according to CPUID.1F from SDM.
>
> Why not choose to export module/tile topology as well?
Excellent question. (and thank you for reading the SDM:-)
While it is true that there are shipping products with
software-visible CPU modules and tiles,
they shipped before this mechanism was available. As a result, there
are currently zero
products that use this mechanism to enumerate modules and tiles. If
future products
have software-visible modules and tiles, and they choose to use this mechanism,
we can add support for them. But I do not advocate adding code to the kernel
"just in case".
In contrast, the need to support multi-die/package products as soon as
possible is quite clear.
thanks,
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists