If a RAW dump is containing for instance 256 logical CPUs (2 sockets with 64 cores and SMT), they should not be considered as a 128 cores CPU with SMT.
Since Zen-based CPUs, cpu_id_t::l3_cache is the size of the total L3 cache for the whole chip, while cpu_id_t::l1_cache and cpu_id_t::l2_cache are size for each instances.
This change provide L3 cache size per instance.
Since ff5aafb5f4, xeon-scalable-4114.test and qemu.test are failling because RAW came from a VM.
Since 2b8023f733, godavari-x4.test is failling due to the merge after 9710e7c0ba
* Set CMAKE_C_FLAGS_DEBUG to display warnings during build
CI workflows are reporting warnings. Adding more C flags here help to avoid that.
* Add new types
* Add set_cpu_affinity function
* Add cpu_identify_all function
* Add cpu_request_core_type function
* Add cpuid_get_all_raw_data, cpuid_serialize_all_raw_data and cpuid_deserialize_all_raw_data functions
* Detect hybrid architecture for Intel CPUs
* Update cpuid_tool to detect all CPU logical cores
* Rename tests subdirectories for Intel Core
* Update all tests
Since e4309a6c4bc3ad875711a1599cba01a205b3103e, new fields are reported by cpuid_tool
* Add Intel Alder Lake
Fix#157
* Remove convert_instlatx64.c
This tool is not useful anymore because the cpuid_deserialize_raw_data_internal() function can natively parse them since 5667e1401c
* Fix affinity_mask computation
* Define _GNU_SOURCE in configure.ac
Forgotten in 4f80964db5
* Use dynamic raw array in cpu_raw_data_array_t
* Add cpu_affinity_mask_t type
* Improve set_cpu_affinity function
- Print a warning if logical CPU number is not supported on operating system
- Return a boolean value in case of success instead of an integer
* Improve cpu_identify_all and cpu_request_core_type functions
* Use dynamic array for cpu_types in system_id_t
This commit also adds cleanups, fixes and consistency
* Tests: update Ryzen 5 Matisse with all CPU cores
* Add affinity_mask_str_r function and address other comments
- Fixed cpuid_grow_raw_data_array and cpu_raw_data_array_t.logical_cpu_t with the correct type
- Added a note about hard limit of cpu_raw_data_array_t
- Fixed a typo in cpuid_deserialize_raw_data_internal
* Fix build on Windows
Score for entry 'Bloomfield (Xeon)' is 10 with this CPU
So it does not match with entry 'Sandy Bridge (Xeon)' (also score 10)
Adding this new entry increase score to 12, and fixing this issue
CloseX0rg/CPU-X#182
Result before this patch:
Checking enum `cpu_feature_t': 113 elements; max size (CPU_FLAGS_MAX=128)... OK
Checking enum `cpu_hint_t': 1 elements; max size (CPU_HINTS_MAX=16)... OK
Checking enum `cpu_sgx_feature_t': 2 elements; max size (SGX_FLAGS_MAX=14)... OK
Finding features:
..Mismatch - cpuid_main.c:688 - `AVX512VNNI' vs `avx512_vnni'
..Mismatch - cpuid_main.c:689 - `AVX512VBMI' vs `avx512_vbmi'
..Mismatch - cpuid_main.c:690 - `AVX512VBMI2' vs `avx512_vbmi2'
cpuid_main.c: 113 features described
Found 113 total features and 113 named features
Checking whether all features have detection code... FAILED:
..No detection code for CPU_FEATURE_SSE5
Reported via http://libcpuid.sourceforge.net/bugreport.php
The test in particular has no brand string, which was causing the
misdetection (as is the case with a lot of other models, libcpuid
relies on accurate brand string being programmed by the BIOS in
order to do the detection).
The actual CPU was a Pentium-III based Celeron (SL54Q), but it
was detected as "Pentium III (Coppermine)".
A bit of historical trivia: for the related Tualatin models, if
the BIOS doesn't enter a brand string, there might be NO WAY to
tell a regular P-3 and a P-3 Celeron apart: P-3s have variants
with 256KiB and 512KiB L2 cache, while the Celerons are 256 KiB, so
a 256KiB regular P3 is no different than its corresponding Celeron.
Only the FSB is different, but there's no way to detect this via
CPUID.
For the Coppermines its an easier case: Celerons are always 128KiB,
and Pentia are 256KiB, so I've added this distinction in the tables.
Add support for detecting Coffee Lake i[357]s. Test included.
Thanks to @X0rg for reporting and to @exdeus for the raw cpu data.
The detection here relies on Kaby and Coffee lakes having different
number of cores for the equivalent brand:
i3: 2 cores in Kaby, 4 in Coffee
i5 and i7: 4 cores in Kaby, 6 in Coffee.
Add support for detecting RDSEED and ADX instructions.
Use RDSEED instead of RTM to ascertain that the CPU is
Broadwell or later in recog_intel.c. This fixes
detection discrepancies on Linux, where RTM is not
made available (I guess there's no kernel support for it).
The two new flags are also now detected in the Broadwell
and Skylake tests. Update them as well.
Improved parsing of brand strings for both Pineview and Cedarview
Atoms.
Add tests for both the Pineview Atom, and also Broadwell-E
(forgotten in a previous commit).
The test is a snapshot of a Haswell i7 (a.k.a. "Crystalwell") core.
This is the only test in the test DB right now which has lines for
L4 cache size, associativity and cacheline size different than "-1".
Also update create_test.py to accommodate for the new fields.
According to wikipedia, cpu-world and some cpu-z screenshots, these processors
do have a code name and it's willamette, northwood, prescott or cedar mill
Signed-off-by: Veselin Georgiev <anrieff@gmail.com>
The reason was that the invocation of the cpuid_tool through the makefile
was using LD_LIBRARY_PATH=. to force link&use of the latest-build libcpuid
library. This doesn't seem to work, so using LD_PRELOAD to explicitly load
libcpuid.so into cpuid_tool.
The committed approach of course doesn't work on Mac OS X, where
make test-old should be used.
