Hybrid CPU topologies combine processors with more than one type of
micro-architecture. Hence, it is possible that individual CPUs support
slightly different features (e.g., performance counters) and different
performance properties. Thus, there may be user space entities interested
in knowing the topology of the system based on the types of available
CPUs.
Currently, there exists an interface for the CPU capacity (/sys/devices/
system/cpu/cpuX/cpu_capacity). However, CPU capacity does not always map
to CPU types (by the way, I will submit a separate series to bring such
interface to x86).
This series proposes the new interface /sys/devices/system/cpu/types
which, in hybrid parts, creates a subdirectory for each type of CPU.
Each subdirectory contains a CPU list and a CPU map that user space can
query.
Patch 1 of the series proposes the generic interface, with hooks
that architectures can override to suit their needs. The three patches
patches implement such interface for x86 (as per request from Boris,
I pulled patch 2 from a separate submission [1]).
Thanks and BR,
Ricardo
[1]. https://lkml.org/lkml/2020/10/2/1013
Ricardo Neri (4):
drivers core: Introduce CPU type sysfs interface
x86/cpu: Describe hybrid CPUs in cpuinfo_x86
x86/cpu/intel: Add function to get name of hybrid CPU types
x86/cpu/topology: Implement the CPU type sysfs interface
.../ABI/testing/sysfs-devices-system-cpu | 13 ++
arch/x86/include/asm/intel-family.h | 4 +
arch/x86/include/asm/processor.h | 13 ++
arch/x86/include/asm/topology.h | 2 +
arch/x86/kernel/cpu/common.c | 3 +
arch/x86/kernel/cpu/cpu.h | 3 +
arch/x86/kernel/cpu/intel.c | 23 ++
arch/x86/kernel/cpu/topology.c | 23 ++
drivers/base/cpu.c | 214 ++++++++++++++++++
include/linux/cpu.h | 12 +
include/linux/cpuhotplug.h | 1 +
11 files changed, 311 insertions(+)
--
2.17.1
Recent Intel processors combine CPUs with different types of micro-
architecture in the same package. There may be applications interested in
knowing the type topology of the system. For instance, it can be used to
to determine which subsets of CPUs share a common feature.
Implement cpu_type sysfs interfaces for Intel processors.
For example, in a system with four Intel Atom CPUs and one Intel Core CPU,
these entries look as below. In this example, the native model IDs for
both types of CPUs are 0:
user@host:~$: ls /sys/devices/system/cpu/types
intel_atom_0 intel_core_0
user@host:~$ ls /sys/devices/system/cpu/types/intel_atom_0
cpulist cpumap
user@host:~$ ls /sys/devices/system/cpu/types/intel_core_0
cpulist cpumap
user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpumap
0f
user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpulist
0-3
user@nost:~$ cat /sys/devices/system/cpu/types/intel_core/cpumap
10
user@host:~$ cat /sys/devices/system/cpu/types/intel_core/cpulist
4
Cc: Andi Kleen <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Kan Liang <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: "Ravi V. Shankar" <[email protected]>
Cc: Srinivas Pandruvada <[email protected]>
Cc: [email protected]
Reviewed-by: Tony Luck <[email protected]>
Suggested-by: Len Brown <[email protected]> # Necessity of the interface
Suggested-by: Dave Hansen <[email protected]> # Details of the interface
Signed-off-by: Ricardo Neri <[email protected]>
---
arch/x86/include/asm/topology.h | 2 ++
arch/x86/kernel/cpu/topology.c | 23 +++++++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index f4234575f3fd..d4a3e1ce8338 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -218,4 +218,6 @@ static inline void arch_set_max_freq_ratio(bool turbo_disabled)
}
#endif
+#define CPUTYPES_MAX_NR 2
+
#endif /* _ASM_X86_TOPOLOGY_H */
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index d3a0791bc052..709fc473f905 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -153,3 +153,26 @@ int detect_extended_topology(struct cpuinfo_x86 *c)
#endif
return 0;
}
+
+u32 arch_get_cpu_type(int cpu)
+{
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+ if (cpu < 0 || cpu >= nr_cpu_ids)
+ return 0;
+
+ return c->x86_cpu_type;
+}
+
+bool arch_has_cpu_type(void)
+{
+ return boot_cpu_has(X86_FEATURE_HYBRID_CPU);
+}
+
+const char *arch_get_cpu_type_name(u32 cpu_type)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ return intel_get_hybrid_cpu_type_name(cpu_type);
+
+ return NULL;
+}
--
2.17.1
Provided a human-friendly string name for each type of CPU micro-
architecture in Intel hybrid parts. This string is to be used in the
CPU type sysfs interface.
In order to uniquely identify CPUs of the same type, compose the name
string as <cpu_type_name>_<native_model_id_nr>.
Cc: Andi Kleen <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Kan Liang <[email protected]>
Cc: Len Brown <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: "Ravi V. Shankar" <[email protected]>
Cc: Srinivas Pandruvada <[email protected]>
Cc: [email protected]
Reviewed-by: Tony Luck <[email protected]>
Signed-off-by: Ricardo Neri <[email protected]>
---
arch/x86/include/asm/intel-family.h | 4 ++++
arch/x86/kernel/cpu/cpu.h | 3 +++
arch/x86/kernel/cpu/intel.c | 23 +++++++++++++++++++++++
3 files changed, 30 insertions(+)
diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 5e658ba2654a..4ec2272e0049 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -133,4 +133,8 @@
/* Family 5 */
#define INTEL_FAM5_QUARK_X1000 0x09 /* Quark X1000 SoC */
+/* Types of CPUs in hybrid parts. */
+#define INTEL_HYBRID_TYPE_ATOM 0x20
+#define INTEL_HYBRID_TYPE_CORE 0x40
+
#endif /* _ASM_X86_INTEL_FAMILY_H */
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 9d033693519a..b4474238e1f3 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -56,8 +56,11 @@ extern __ro_after_init enum tsx_ctrl_states tsx_ctrl_state;
extern void __init tsx_init(void);
extern void tsx_enable(void);
extern void tsx_disable(void);
+extern const char *intel_get_hybrid_cpu_type_name(u32 cpu_type);
#else
static inline void tsx_init(void) { }
+static inline const char *intel_get_hybrid_cpu_type_name(u32 cpu_type)
+{ return NULL; }
#endif /* CONFIG_CPU_SUP_INTEL */
extern void get_cpu_cap(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 59a1e3ce3f14..e1dee382cf98 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1191,3 +1191,26 @@ void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c)
cpu_model_supports_sld = true;
split_lock_setup();
}
+
+static char hybrid_name[64];
+
+const char *intel_get_hybrid_cpu_type_name(u32 cpu_type)
+{
+ u32 native_model_id = cpu_type & X86_HYBRID_CPU_NATIVE_MODEL_ID_MASK;
+ u8 type = cpu_type >> X86_HYBRID_CPU_TYPE_ID_SHIFT;
+
+ switch (type) {
+ case INTEL_HYBRID_TYPE_ATOM:
+ snprintf(hybrid_name, sizeof(hybrid_name), "intel_atom_%u",
+ native_model_id);
+ break;
+ case INTEL_HYBRID_TYPE_CORE:
+ snprintf(hybrid_name, sizeof(hybrid_name), "intel_core_%u",
+ native_model_id);
+ break;
+ default:
+ return NULL;
+ }
+
+ return hybrid_name;
+}
--
2.17.1
On 10/2/20 6:17 PM, Ricardo Neri wrote:
> +u32 arch_get_cpu_type(int cpu)
> +{
> + struct cpuinfo_x86 *c = &cpu_data(cpu);
> +
> + if (cpu < 0 || cpu >= nr_cpu_ids)
> + return 0;
> +
> + return c->x86_cpu_type;> +}
Hi,
Consider using
#include <linux/nospec.h>
and array_index_nospec() to avoid speculation problems on cpu_data.
cheers.
--
~Randy
Hi Ricardo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on tip/master driver-core/driver-core-testing linus/master v5.9-rc7 next-20201002]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/drivers-core-Introduce-CPU-type-sysfs-interface/20201003-091754
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 238c91115cd05c71447ea071624a4c9fe661f970
config: x86_64-randconfig-a012-20201002 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bcd05599d0e53977a963799d6ee4f6e0bc21331b)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# https://github.com/0day-ci/linux/commit/6e37c052cde780c58a9dd815e667d89538e30579
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Ricardo-Neri/drivers-core-Introduce-CPU-type-sysfs-interface/20201003-091754
git checkout 6e37c052cde780c58a9dd815e667d89538e30579
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
return boot_cpu_has(X86_FEATURE_HYBRID_CPU);
^
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
>> arch/x86/kernel/cpu/topology.c:169:22: error: use of undeclared identifier 'X86_FEATURE_HYBRID_CPU'
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
vim +/X86_FEATURE_HYBRID_CPU +169 arch/x86/kernel/cpu/topology.c
166
167 bool arch_has_cpu_type(void)
168 {
> 169 return boot_cpu_has(X86_FEATURE_HYBRID_CPU);
170 }
171
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
On Fri, Oct 02, 2020 at 06:17:41PM -0700, Ricardo Neri wrote:
> Patch 1 of the series proposes the generic interface, with hooks
> that architectures can override to suit their needs. The three patches
> patches implement such interface for x86 (as per request from Boris,
> I pulled patch 2 from a separate submission [1]).
So I ask you to show me the whole thing, how this is supposed to be used
in a *real* use case and you're sending me a couple of patches which
report these heterogeneous or whatever they're gonna be called CPUs.
Are you telling me that all this development effort was done so that
you can report heterogeneity in sysfs? Or you just had to come up with
*something*?
Let me try again: please show me the *big* *picture* with all the code
how this is supposed to be used. In the patches I read a bunch of "may"
formulations of what is possible and what userspace could do and so on.
Not that - show me the *full* and *real* use cases which you are
enabling and which justify all that churn. Instead of leaving it all to
userspace CPUID and the kernel not caring one bit.
Does that make more sense?
> [1]. https://lkml.org/lkml/2020/10/2/1013
For supplying links, we use lore.kernel.org/r/<message-id> solely.
Please use that from now on.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Oct 02, 2020 at 06:17:45PM -0700, Ricardo Neri wrote:
> Recent Intel processors combine CPUs with different types of micro-
> architecture in the same package. There may be applications interested in
> knowing the type topology of the system. For instance, it can be used to
> to determine which subsets of CPUs share a common feature.
>
> Implement cpu_type sysfs interfaces for Intel processors.
>
> For example, in a system with four Intel Atom CPUs and one Intel Core CPU,
> these entries look as below. In this example, the native model IDs for
> both types of CPUs are 0:
>
> user@host:~$: ls /sys/devices/system/cpu/types
> intel_atom_0 intel_core_0
>
> user@host:~$ ls /sys/devices/system/cpu/types/intel_atom_0
> cpulist cpumap
>
> user@host:~$ ls /sys/devices/system/cpu/types/intel_core_0
> cpulist cpumap
>
> user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpumap
> 0f
>
> user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpulist
> 0-3
>
> user@nost:~$ cat /sys/devices/system/cpu/types/intel_core/cpumap
> 10
>
> user@host:~$ cat /sys/devices/system/cpu/types/intel_core/cpulist
> 4
You used the same changelog text here as you did in patch 1/4, why?
thanks,
greg k-h
On Sat, Oct 03, 2020 at 10:49:34AM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 06:17:41PM -0700, Ricardo Neri wrote:
> > Patch 1 of the series proposes the generic interface, with hooks
> > that architectures can override to suit their needs. The three patches
> > patches implement such interface for x86 (as per request from Boris,
> > I pulled patch 2 from a separate submission [1]).
>
> So I ask you to show me the whole thing, how this is supposed to be used
> in a *real* use case and you're sending me a couple of patches which
> report these heterogeneous or whatever they're gonna be called CPUs.
>
> Are you telling me that all this development effort was done so that
> you can report heterogeneity in sysfs? Or you just had to come up with
> *something*?
>
> Let me try again: please show me the *big* *picture* with all the code
> how this is supposed to be used. In the patches I read a bunch of "may"
> formulations of what is possible and what userspace could do and so on.
>
> Not that - show me the *full* and *real* use cases which you are
> enabling and which justify all that churn. Instead of leaving it all to
> userspace CPUID and the kernel not caring one bit.
>
> Does that make more sense?
Yes Boris, thanks for the clarification. The proposed sysfs interface is
one instance in which we use cpuinfo_x86.x86_cpu_type. I have other
changes that use this new member. I will post them.
>
> > [1]. https://lkml.org/lkml/2020/10/2/1013
>
> For supplying links, we use lore.kernel.org/r/<message-id> solely.
> Please use that from now on.
Sure Boris, I will use lore.kernel.org in the future.
Thanks and BR,
Ricardo
On Sat, Oct 03, 2020 at 10:55:06AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 06:17:45PM -0700, Ricardo Neri wrote:
> > Recent Intel processors combine CPUs with different types of micro-
> > architecture in the same package. There may be applications interested in
> > knowing the type topology of the system. For instance, it can be used to
> > to determine which subsets of CPUs share a common feature.
> >
> > Implement cpu_type sysfs interfaces for Intel processors.
> >
> > For example, in a system with four Intel Atom CPUs and one Intel Core CPU,
> > these entries look as below. In this example, the native model IDs for
> > both types of CPUs are 0:
> >
> > user@host:~$: ls /sys/devices/system/cpu/types
> > intel_atom_0 intel_core_0
> >
> > user@host:~$ ls /sys/devices/system/cpu/types/intel_atom_0
> > cpulist cpumap
> >
> > user@host:~$ ls /sys/devices/system/cpu/types/intel_core_0
> > cpulist cpumap
> >
> > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpumap
> > 0f
> >
> > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom/cpulist
> > 0-3
> >
> > user@nost:~$ cat /sys/devices/system/cpu/types/intel_core/cpumap
> > 10
> >
> > user@host:~$ cat /sys/devices/system/cpu/types/intel_core/cpulist
> > 4
>
> You used the same changelog text here as you did in patch 1/4, why?
In both changesets, if merged, somebody could conveniently do git show
on either commit quickly see the result intent of the changeset.
Would it make it better if in patch 1/4 I put an hypothetical generic
example?
Something like:
user@host:~$: ls /sys/devices/system/cpu/types
<arch>_<type_a> <arch><type_b>
Thanks and BR,
Ricardo
Hi Ricardo
Adding some people who might be interested.
On 10/02/20 18:17, Ricardo Neri wrote:
> Hybrid CPU topologies combine processors with more than one type of
> micro-architecture. Hence, it is possible that individual CPUs support
> slightly different features (e.g., performance counters) and different
> performance properties. Thus, there may be user space entities interested
> in knowing the topology of the system based on the types of available
> CPUs.
>
> Currently, there exists an interface for the CPU capacity (/sys/devices/
> system/cpu/cpuX/cpu_capacity). However, CPU capacity does not always map
> to CPU types (by the way, I will submit a separate series to bring such
> interface to x86).
Why do you need to do this mapping?
>
> This series proposes the new interface /sys/devices/system/cpu/types
> which, in hybrid parts, creates a subdirectory for each type of CPU.
> Each subdirectory contains a CPU list and a CPU map that user space can
> query.
Why user space needs to query this info?
The rationale is missing the intention behind all of this. It seems you're
expecting software to parse this info and take decisions based on that?
Thanks
--
Qais Yousef
>
> Patch 1 of the series proposes the generic interface, with hooks
> that architectures can override to suit their needs. The three patches
> patches implement such interface for x86 (as per request from Boris,
> I pulled patch 2 from a separate submission [1]).
>
> Thanks and BR,
> Ricardo
>
> [1]. https://lkml.org/lkml/2020/10/2/1013
>
> Ricardo Neri (4):
> drivers core: Introduce CPU type sysfs interface
> x86/cpu: Describe hybrid CPUs in cpuinfo_x86
> x86/cpu/intel: Add function to get name of hybrid CPU types
> x86/cpu/topology: Implement the CPU type sysfs interface
>
> .../ABI/testing/sysfs-devices-system-cpu | 13 ++
> arch/x86/include/asm/intel-family.h | 4 +
> arch/x86/include/asm/processor.h | 13 ++
> arch/x86/include/asm/topology.h | 2 +
> arch/x86/kernel/cpu/common.c | 3 +
> arch/x86/kernel/cpu/cpu.h | 3 +
> arch/x86/kernel/cpu/intel.c | 23 ++
> arch/x86/kernel/cpu/topology.c | 23 ++
> drivers/base/cpu.c | 214 ++++++++++++++++++
> include/linux/cpu.h | 12 +
> include/linux/cpuhotplug.h | 1 +
> 11 files changed, 311 insertions(+)
>
> --
> 2.17.1
>
On Tue, Oct 06, 2020 at 09:51:53AM +0100, Qais Yousef wrote:
> Hi Ricardo
Hi Qais,
Thanks for chiming in.
>
> Adding some people who might be interested.
>
> On 10/02/20 18:17, Ricardo Neri wrote:
> > Hybrid CPU topologies combine processors with more than one type of
> > micro-architecture. Hence, it is possible that individual CPUs support
> > slightly different features (e.g., performance counters) and different
> > performance properties. Thus, there may be user space entities interested
> > in knowing the topology of the system based on the types of available
> > CPUs.
> >
> > Currently, there exists an interface for the CPU capacity (/sys/devices/
> > system/cpu/cpuX/cpu_capacity). However, CPU capacity does not always map
> > to CPU types (by the way, I will submit a separate series to bring such
> > interface to x86).
>
> Why do you need to do this mapping?
>
> >
> > This series proposes the new interface /sys/devices/system/cpu/types
> > which, in hybrid parts, creates a subdirectory for each type of CPU.
> > Each subdirectory contains a CPU list and a CPU map that user space can
> > query.
>
> Why user space needs to query this info?
>
> The rationale is missing the intention behind all of this. It seems you're
> expecting software to parse this info and take decisions based on that?
I propose this interface to be consumed for application or libraries
wanting to know the topology of the system. Perhaps, a utility program
that wants to depict CPUs by type. Another example is a policy manager
wanting to create a cgroup cpuset of CPUs of a given type for
performance reasons. Similarly, a program may want to affinitize itself
to a type of CPU, if for instance certain performance events are only
counted on a given CPU type.
Also, an interface with cpumasks makes it convenient for userspace to
not have to traverse each CPU individually.
a) add the type of each CPU in /proc/cpuinfo
b) add the type of each CPU in /sys/devices/system/cpu/cpu#/type
c) for performance, derive the CPU type from
/sys/devices/system/cpu/cpu#/cpu_capacity
d) add an interface similar to what I propose in this series.
None of this imply that certain instructions will be able to run on one
type of CPU but not on another. Instead, better performance may be
obtained on one type CPU vs another.
Thanks and BR,
Ricardo