Show the number of the number of physical socket even if the sysfs doesn't
have the physical socket information.
Note, lscpu shows the number of physical socket as 'Socket(s):' only if
root user runs it because accessing the DMI table requires root
privilege.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
lscpu may show the wrong number of sockets if the machine is aarch64 and
doesn't have ACPI PPTT.
That's because lscpu shows the number of sockets by using a sysfs entry
(cpu/cpuX/topology/core_siblings). The sysfs entry is set by MPIDR_EL1
register if the machine doesn't have ACPI PPTT. MPIDR_EL1 doesn't show
the physical socket information directly. It shows the affinity level.
According to linux/arch/arm64/kernel/topology.c:store_cpu_topology(),
the top level of affinity is called as 'Cluster'.
Use Cluster instead of Socket on the machine which doesn't have ACPI PPTT.
This patch is useful for aarch64 machine which is based on ARM
SBBR v1.0 and v1.1, the specs don't require ACPI PPTT. ARM SBBR v1.2
requires ACPI PPTT.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
After commit: 367c85c47 ("lscpu: use SMBIOS tables on ARM for lscpu"),
Model name for A64FX shows like as:
Model name: 461F0010
That's because 367c85c47 changes to get the modelname from Processor
Version of SMBIOS.
To fix that, use the hard corded table to show the "Model name" and
add two new lines; "BIOS Vendor ID" and "BIOS Model name" to show the
SMBIOS information.
lscpu shows the SMBIOS information when root user runs it because
accessing the SMBIOS information requires root privilege.
[kzak@redhat.com: - port the patch to new lscpu code]
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
* keep global (cputype) bogomips
* add per-CPU bogomips
* use bogomips from the first CPU as global (for cputype) if /proc/cpuinfo does not provide global bogomips
* add BOGOMIPS column for to -e/-p output
Signed-off-by: Karel Zak <kzak@redhat.com>
Let's make it more robust and readable. The sysinfo file on s390 may
contain zeros, so we need to check the values and fallback to data
from shared maps if necessary.
Signed-off-by: Karel Zak <kzak@redhat.com>
Note that cxt->ncaches is number of all instances, but we split
output according to split output according to caches names.
Signed-off-by: Karel Zak <kzak@redhat.com>
* keep one sharedmap per cache instance
* initialize topology IDs to -1
* rewrite -e code to use a new data structs
Signed-off-by: Karel Zak <kzak@redhat.com>
The cache is identified by Type, Level and ID, the ID is unique cache
instance identifier (of the type).
This changes forces lscpu allocate more lscpu_cache instances (than
old version), but now we're ready for arbitrary scenario where
different CPU types share caches and the same cache type uses
different size in different instances, etc.
Signed-off-by: Karel Zak <kzak@redhat.com>
This is the first step in conversion from old lscpu to the new code.
The patch removes obsolete code from lscpu.c and lscpu.h. The old
output code in lscpu.c is temporary disabled by #ifdef due to
incompatibility between old and new internal APIs -- this will be
changed later by small steps to make all all the changes review-able.
Signed-off-by: Karel Zak <kzak@redhat.com>
The shared cache info for s390 can be found in /proc/cpuinfo.
lscpu without any options already processes this info. Fix this
in lscpu -C and provide detailed stat.
Test for s390:
./lscpu -C
NAME ONE-SIZE ALL-SIZE WAYS TYPE LEVEL SETS PHY-LINE COHERENCY-SIZE
L1d 128K 256K 8 Data 1 64 256
L1i 128K 256K 8 Instruction 1 64 256
L2d 4M 8M 8 Data 2 2048 256
L2i 2M 4M 8 Instruction 2 1024 256
L3 128M 32 Unified 3 16384 256
L4 672M 42 Unified 4 65536 256
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
The drawers and books are optional and not supported on all
architectures and in this case drawers/books relevant arrays are not
allocated, so don't access it although user wants it
(e.g. "lscpu -p -y --output-all").
This patch also cleans up arrays allocation to make it more readable
and robust against edit mistakes.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1801760
Signed-off-by: Karel Zak <kzak@redhat.com>
We usually check lookup() return value. Let's do it in this case too.
It seems static analyzers will be happy with consistent code.
Signed-off-by: Karel Zak <kzak@redhat.com>
[sys-utils/lscpu.c:1783] -> [sys-utils/lscpu.c:1785]: (warning) Either the
condition 'desc' is redundant or there is possible null pointer dereference: desc.
[sys-utils/lscpu.c:1840] -> [sys-utils/lscpu.c:1842]: (warning) Either the
condition 'desc' is redundant or there is possible null pointer dereference: desc.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
As the title tells this change indeed fixes floating point exception, but
post processing as value overwrite feels a wrong. Possibly something in
input is making cpu set count to go wrong, but I could not get my head
around what could it be. Anyway avoiding division by zero seems better than
crashing so lets do this atleast for now.
Caused-by: e5f721132e
Addresses: https://github.com/karelzak/util-linux/issues/788
Reported-by: Lars Wendler <polynomial-c@gentoo.org>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>