Problem:"lscpu frequency-info" command was always reading CPU0
max and min frequencies. If CPU0 is guarded or offline then it used to
display max and min frequencies as NULL.
This patch will read overall CPU max and min frequencies.
Test Results:
Before Patch:
#lscpu (CPU0 is guarded/offline)
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 120
On-line CPU(s) list: 8-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 32-63
NUMA node16 CPU(s): 64-95
NUMA node17 CPU(s): 96-127
With Patch:
# ./lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 120
On-line CPU(s) list: 8-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 4322.0000
CPU min MHz: 2061.0000
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 32-63
NUMA node16 CPU(s): 64-95
NUMA node17 CPU(s): 96-127
[kzak@redhat.com: - cpu_{max,min}_mhz() refactoring]
Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Windows 10 implements Windows Subsystem for Linux (WSL).
WSL does not implement support for SIGSEGV handler, which is used inside
is_vmware_platform(). As a result, lscpu crashes there.
Implement WSL detection, and as a side effect, work around the crash.
Note that none of existing virtualization types exactly matches.
But the the closest would be "container".
References:
Provide a way to positively detect WSL from an app compiled on Linux.
https://github.com/Microsoft/BashOnWindows/issues/423
missing support for SIGSEGV handler
https://github.com/Microsoft/BashOnWindows/issues/1637
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
It seems that aarch64 uses a different names for some /proc/cpuinfo
fields (e.g. intel: bogomips, flags, and aarch64: BogoMIPS, features, ...)
Addresses: https://github.com/karelzak/util-linux/issues/392
Signed-off-by: Karel Zak <kzak@redhat.com>
lscpu calculates the number of threads per core by dividing the number
of online cpus with the number of cores. This may or may not give the
correct number of threads per core depending on the number of online
CPUs (and which CPUs are online).
At least on s390 there is a new "max thread id" field within
/proc/cpuinfo present which reliably allows us to tell the number of
threads per core. Let's use this instead, like we already have also
special treatment to figure out the number core per socket etc. on
s390.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
lscpu can skip all CPUs which are possible but not present. For
configurations where a lot of CPUs are possible but only few CPUs are
present this saves a lot of pointless glibc/system calls.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
With the --physical option lscpu will use the IDs that are reported by
the kernel (e.g. core id for the CORE column) instead of calculating
them on it's own.
This has the advantage that it is possible to tell on which physical
hardware CPUs a Linux instance runs. The logical IDs that lscpu
generates on it own are based on comparing of CPU masks and may or may
not be identical with the physical IDs.
If the kernel was unable to retrieve an ID for a topology element then
the corresponding sysfs file will normally contain "-1". In the
extended and parsable output a dash "-" will be displayed for such
cases.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The Linux kernel exposes the cache topology via sysfs. However on
virtualized machines like s390 the cache topology contains only cpu
private caches.
For shared caches it is not known which cpus share them. The
hypervisor would have to update this information whenever a virtual
cpu would be scheduled on a different physical cpu and make the guest
aware of that change. Given that there is hardly any benefit, if it
all, this isn't done.
However it is still of interest to know about the non-private
caches. Therefore this information is available via /proc/cpuinfo at
least on s390.
This patch adds additional lines to the summary output for all shared
caches for which information can be found in /proc/cpuinfo, since we
know these aren't exposed via sysfs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Show also the machine type within the lscpu output. With the machine
type it is possible to identify the cpu generation and the supported
features.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
s390 machines provide static and dynamic cpu mhz information via
/proc/cpuinfo. The static cpu mhz is the normal cpu frequency a cpu is
supposed to run with.
The dynamic cpu mhz is the actual frequency a cpu is running
with. This is usually the same as the static cpu mhz. Note that this
values are different to the min/max mhz values available on other
architecutes. The min/max values are unknown.
This patch adds two new fields to the summary output which display
these two values.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The new drawer support did have a type in the summary output:
it reported Drawers(s) instead of Drawer(s). Fix this.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The s390 architecture gained another cpu topology level called
"drawer" which is above the book level.
Add support for this to lscpu.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Fix various typos in error messages, warnings, debug strings,
comments and names of static functions.
Signed-off-by: Sebastian Rasmussen <sebras@gmail.com>
Nowadays, most Intel CPUs have "cpuid faulting" available which could trap
the execution of "cpuid" instruction when CPL>0 with GP fault. Thus,
"cpuid" instruction could trap to Xen hypervisor on the paravirtualized PV
guest on most servers today, except on old CPUs prior to 2011. On CPU after
2011, Xen will put "XenVMMXenVMM" on both HVM and PV guests, which could
have lscpu command erroneously classify the guest as type "full". The
current lscpu command, which is based on "cpuid" instruction, still assumes
that it will not cause the trap to Xen hypervisor on Xen PV guest and uses
/proc/xen to identify whether it's running on PV DomU or not. To identify
this kind of information under the help of
/sys/hypervisor/properties/features would be more accurate for the CPU
nowadays. The bit 5 (XENFEAT_mmu_pt_update_preserve_ad) of the features
will be set only when it's running on Xen PV domain. The combo of bit 3 and
8 (XENFEAT_supervisor_mode_kernel and XENFEAT_hvm_callback_vector) will be
set simultaneously only when it's running on Xen PVH domain.
[kzak@redhat.com: - add path_exist()]
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Now the first one of certain ambiguous tags wins. Alternatively to
this patch we could have called free() before xstrdup().
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Avoid ifdef which does not work with --sysroot. Our existing test
dumps produce even better output now for ppc and sparc.
The logic moved to the printing section.
CC: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This patch reverts 3ac03fe4d2 for
snapshots (--sysroot).
Yeah, poor-man solution. It would be really nice to have runtime
detection to support model overwriting also on snapshots.
Signed-off-by: Karel Zak <kzak@redhat.com>
On Power System, lspcu presently displays system model number instead of
processor model name. 'model' tag in cpuinfo contains system model name,
not processor model. Instead it uses 'cpu' tag for processor model name.
Also it uses 'revision' tag for processor model.
Fix lspcu so that it displays processor model number. Also display processor
model name.
cpuinfo output on Power System:
...
...
processor : 127
cpu : POWER8E (raw), altivec supported
clock : 4322.000000MHz
revision : 2.1 (pvr 004b 0201)
timebase : 512000000
platform : PowerNV
model : 8286-42A
machine : PowerNV 8286-42A
firmware : OPAL
Output without this patch:
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 4
NUMA node(s): 4
Model: 8286-42A
...
...
Output with this patch:
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
...
...
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
lscpu currently prints information for CPUs configured in the system.
In case of KVM or other virtualized guest operating systems, this
refers to the virtual system, and bears no relation to the physical
topology of the system.
It would be useful if lscpu could also display the physical topology
info when available:
$ ./lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 16
NUMA node(s): 1
Model: IBM pSeries (emulated by qemu)
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 64K
L1i cache: 32K
NUMA node0 CPU(s): 0-15
Physical sockets: 2 <<< New
Physical chips: 4 <<< New
Physical cores/chip: 4 <<< New
For now, physical topology information is available on platforms that
support the following RTAS (Real time abstraction service) call provided
by librtas:
rtas_get_sysparm(PROCESSOR_MODULE_INFO).
Currently this call is available to the PowerVM (pHYP) guests on PowerPC.
With a patch propoosed to PowerKVM, this RTAS call would also be available
to PowerKVM guests.
Based on input from Nishanth Aravamudan and Karel Zak.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
We care about /proc/device-tree/compatible content...
The patch also removes unnecessary path_exist(), it seems good enough
to call open() rather than access() + open().
Addresses: https://github.com/karelzak/util-linux/issues/218
Signed-off-by: Karel Zak <kzak@redhat.com>
Intel compiler complains about printf style function calls with trivial
format string and no other arguments. Like this one:
../sys-utils/ipcrm.c(117): warning #2279: printf/scanf format not a string literal and no format arguments
err(EXIT_FAILURE, iskey ? _("key failed") : _("id failed"));
This adds a concise description of a tool to its usage text.
A first form of this patch was proposed by Steven Honeyman
(see http://www.spinics.net/lists/util-linux-ng/msg09994.html).
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
AddressSanitizer is identifying the __asm__ segment as suspicious.
==1215==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x0000004ccffd bp 0x7fff9b7184f0 sp 0x7fff9b7184e0 T0)
#0 0x4ccffc in vmware_bdoor /home/src/util-linux/sys-utils/lscpu.c:660
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
there is a theoretical buffer overflow possible in the hypervisor
parsing code of lscpu. It would require a proc entry to return way more
than expected so it's no high priority. But better be safe than sorry.
At first I thought about switching to fgets but there is another
code file that adds a format specifier. The diff is less intrusive
that way, too.
Signed-off-by: Karel Zak <kzak@redhat.com>
CppCheck founds a few wrong arguments in format strings and a NULL
pointer dereference.
Amended version with fixed strcmp() usage.
Signed-off-by: Boris Egorov <egorov@linux.com>
This code is not PIC clean which means it fails to build on hardened
32bit x86 systems (i.e. building as PIE).
While here, optimize the existing cpuid logic slightly.
URL: https://bugs.gentoo.org/518936
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This patch comes from openSUSE / SLE. Original author was probably
Petr Uzel.
Internal SUSE references: fate310255, sr226509
VMmware backdoor assembler code has been fixed for old clang compiler
(travis), see
see http://llvm.org/bugs/show_bug.cgi?id=9379
CC: Stanislav Brabec <sbrabec@suse.cz>
CC: Petr Uzel <petr.uzel@suse.cz>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This patch comes originally from openSUSE / SLE. Author was probably
Petr Uzel.
Internal SUSE references: fate310255, sr226509
In comparison to the original patch we have slightly corrected iSeries
and pSeries detection according to Alexander Graf's comments on
util-linux@vger.kernel.org. Maybe we would need to add some more code
to detect pSeries emulated by Qemu/KVM.
CC: Stanislav Brabec <sbrabec@suse.cz>
CC: Petr Uzel <petr.uzel@suse.cz>
CC: Alexander Graf <agraf@suse.de>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
- add HYPER_VBOX
- improve HYPER_VMWARE
This patch comes from openSUSE / SLE. Original author was probably
Petr Uzel.
Internal SUSE references: fate310255, sr226509
CC: Stanislav Brabec <sbrabec@suse.cz>
CC: Petr Uzel <petr.uzel@suse.cz>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
* rename flags functions to scols_table_enable_*
* rename *_no_foo() functions to _nofoo()
* output formats are mutually exclusive, so don't use flags there
* don't assume symbols in scols_new_table(), use scols_table_set_symbols()
Signed-off-by: Karel Zak <kzak@redhat.com>
There are systems where the size file does not exist. Most badly even
lscpu -p would abort allthough it does not use the size:
$ lscpu -p
lscpu: error: cannot open
/sys/devices/system/cpu/cpu0/cache/index0/size: No such file or directory
This patch does not abort in this case and prints "unknown size" in
human-readable case. For examle on this qemu pcc test machine:
$ lscpu
Architecture: ppc
CPU op-mode(s): 32-bit
Byte Order: Big Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Model: Power Macintosh
BogoMIPS: 33.25
L1d cache: unknown size
L1i cache: unknown size
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Not all file systems support the d_type field and simply checking for
d_type == DT_DIR in is_node_dirent would cause the test suite to fail
if run on (for example) XFS.
The simple fix is to check for DT_DIR or DT_UNKNOWN in is_node_dirent.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
lscpu fails to print proper NUMA node values in a system with
discontinuous nodes. This patch adds support by creating a nodeidx
array to map node numbers.
Based on patch from Madhavan Srinivasan <maddy@linux.vnet.ibm.com>.
Reported-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
lscpu don't work correctly on my system with:
$ cat /sys/devices/system/cpu/possible
0-1,4-5,8-9,12-13
[kzak@redhat.com: - coding style,
- add commit message
- add real_cpu_num() macro,
- fix functions where we need idx as well as CPU number]
Signed-off-by: Karel Zak <kzak@redhat.com>
The lscpu tool only shows the current and max CPU frequencies, however,
in many scenarios this is not enough. If there are energy saving situations
(like some CPUs being idle, or not fully used) the cpugov can lower this value.
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
The existing 'CPU MHz' is usually dynamic value, which CPU governor
changes up on needs of CPU demand. Assuming lscpu is used to gather
information to a hardware inventory the dynamic value is misleading. For
inventing the maximum MHz value is more sensible.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
read_basicinfo() relies on sysfs cpu directories
"/sys/devices/system/cpu/cpu%d" with assumption that cpu
logical number %d is always sequentially assigned for all
CPUs. However, this assumption is not correct with CPU
hot-remove operation since it removes a target sysfs cpu
directory after it is ejected. As a result, lscpu may not
recognize all CPUs.
The issue can be easily reproduced on KVM or VirtualBox,
which supports CPU eject operation, as follows.
1) The system has 4 CPUs
$ lscpu -a -e
CPU NODE SOCKET CORE L1d:L1i:L2 ONLINE
0 0 0 0 0:0:0 yes
1 0 1 1 1:1:1 yes
2 0 2 2 2:2:2 yes
3 0 3 3 3:3:3 yes
2) Eject cpu2
# echo 1 > /sys/bus/acpi/devices/LNXCPU:02/eject
3) lscpu no longer recognizes cpu3 after cpu2 is ejected
$ lscpu -a -e
CPU NODE SOCKET CORE L1d:L1i:L2 ONLINE
0 0 0 0 0:0:0 yes
1 0 1 1 1:1:1 yes
The following changes are made to address this issue.
- Use maxcpus to allocate and parse bitmaps.
- Set desc->ncpu from cpu/present, which includes both on-line
and off-line CPUs.
- Add is_cpu_present() to check if a CPU is present. Ejected
CPUs are not present.
[kzak@redhat.com: - read also /sys/devices/system/cpu/possible mask to
determine maximal number of CPUs,
- err() if possible mask is not found in /sys]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Passing the --all, --online or --offline options for the output summary
doesn't make much sense. It should be limited to the two list output options.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
sys-utils/lscpu.c:1084:8: warning: declaration of 'buf' shadows a previous local [-Wshadow]
sys-utils/lscpu.c:1077:7: warning: shadowed declaration is here [-Wshadow]
sys-utils/lscpu.c:1144:9: warning: declaration of 'buf' shadows a previous local [-Wshadow]
sys-utils/lscpu.c:1077:7: warning: shadowed declaration is here [-Wshadow]
sys-utils/lscpu.c:1196:8: warning: declaration of 'buf' shadows a previous local [-Wshadow]
sys-utils/lscpu.c:1077:7: warning: shadowed declaration is here [-Wshadow]
sys-utils/lscpu.c:1197:7: warning: declaration of 'i' shadows a previous local [-Wshadow]
sys-utils/lscpu.c:1078:6: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
lscpu.c: In function ‘has_pci_device’:
lscpu.c:425:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
lscpu.c:425:28: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-off-by: Karel Zak <kzak@redhat.com>
With -Wall -Werror, compilation of lscpu.c fails with:
Making all in sys-utils
make[2]: Entering directory `/home/petr/upstream/util-linux/sys-utils'
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -include ../config.h -I../include -DLOCALEDIR=\"/usr/share/locale\" -fsigned-char -Wall -Werror -MT lscpu.o -MD -MP -MF .deps/lscpu.Tpo -c -o lscpu.o lscpu.c
lscpu.c: In function ‘print_parsable’:
lscpu.c:971:7: error: operation on ‘p’ may be undefined [-Werror=sequence-point]
cc1: all warnings being treated as errors
Fix by splitting the pointer increment to separate statement.
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
The tool misspellings (https://github.com/lyda/misspell-check)
detected several typos. Command used:
$ git ls-files | grep -v ^po/ | misspellings -f -
* isosize: Fix typo in usage string.
* configure.ac: Fix typo in help string of --enable-most-builds option.
* fdisk: Fix typo in man page.
* libblkid, blkid, mount: Likewise.
* Fix various typos in docs and in source code comments.
Signed-off-by: Bernhard Voelker <mail@bernhard-voelker.de>
The string format is not being passed triggering:
lscpu.c: In function ‘read_hypervisor’:
lscpu.c:545:4: warning: format not a string literal and no format arguments
lscpu.c: In function ‘get_cell_header’:
lscpu.c:904:2: warning: format not a string literal and no format arguments
lscpu.c:904:2: warning: format not a string literal and no format arguments
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Some people complained about the first letter of Yes/No as seen in the
online and configured column in the human readabe output being a capital
letter instead of the expected lower case letter.
So let's try to make everbody happy and convert them to lower case.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Disallow superfluous commands for lscpu like e.g. "lscpu bla" and let it
fail print the help text instead.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Implement "--offline" option which only prints offline cpus. As a side effect
we can get rid of the internal "allcpus" flag, since if we want to print
informations for online and offline cpus we simply set both flags.
When reading sysfs attributes of cpus this is now done for all cpus, since
e.g. the topology informations of the online cpus may influence the
topology informations of the offline cpus. This mainly because online cpus
may contain masks which include offline cpus while offline cpus have a
missing topology directory.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The modifier mod->allcpus must be set earlier and also must be used
earlier. The current code only reads sysfs attributes from online
cpus but skips offline cpus.
So initialize mod->allcpus earlier.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
A couple of these functions already have been copied to chcpu.c,
so it makes sense to move these functions into an own file.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
However I'd like to see one change if you don't object: printing just "N" or
"Y" instead of "No" and "Yes" in the human readable output looks a bit ugly to
me.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Some vendors have several hypervisors. Therefore it makes sense to not only
print out the hypervisor vendor but also the name of the hypervisor.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The parsable output includes only lines of online CPUs. To also include
lines for all offline CPUs the "--all" option can be specified.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
lscpu only prints lines for online CPUs. At least for the human readable
list the offline CPUs are of interest as well. In order to distinguish
between online and offline CPUs introduce the "Online" column.
By default the human readable output now displays online and offline CPUs.
The parsable output is not changed. It will print only lines for online
CPUs as it used to do.
[kzak@redhat.com: - minor changes]
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
CPUs may be in a configured or deconfigured state depending if the CPU resource
may be used by the guest. If a CPU is in configured state the guest may use it
(i.e. set it online). It it is in deconfigured state it cannot use it before
changing its state to configured. Display this CPU attribute as well.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Based on patch from Heiko Carstens <heiko.carstens@de.ibm.com>:
lscpu currently only supports a parsable output which contains a row for
each cpu and its attributes. This output contains only comas as separators
and is hard to read for humans.
Therefore add a new option "-e | --extended" which outputs the rows in a
much more readable (and non-parsable) form. Just like for the -p option a
list of columns can be specified that shall be included in the output.
By default this option will print all columns that contain data.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Add a --version option like most other tools have it.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
First check path before accessing files to be sure they actually exist. This is
necessary when also informations for offline CPUs will be printed. Since we do
not necessarily know if "cpu is offline" means the same as "path does not
exist" just check for it.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Simplify the logic to "always print a ',' for each cache except if it is the
last one. This is also a preparation patch for printing the cache column for
offline CPUs where it would print one colon too much because of the current
logic.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The extended parsable output prints a colon instead of comma between each
item. The case where a CPU doesn't belong to any cache was not converted.
Just fix this.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Fix typo where the comma operator has been introduced.
Use a semicolon instead so we end up with simple assignment expressions.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
This is a preparation patch for chcpu. If a cpu should be added to
a cpu_set where the cpu doesn't fit into the cpu_set this got silently
ignored.
Since the cpu-list is user space provided it should be checked if cpus
are specified that are completely out of range of the system.
In order to do that add a parameter which specifies if cpulist_parse()
should fail if it parses a cpu-list with "impossible" cpus.
The current callers have been converted so they behave like before.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Print also the physical cpu address for each logical cpu in parsable
output if selected and present via sysfs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
When running in different dispatching mode the virtual cpus may
have different polarizations.
E.g. in "vertical" mode cpus may have a polarization of "vertical:high"
which means the virtual cpu has dedicated physical cpu assigned.
Print this information in the parsable output.
Note that this breaks the current rule that
a) the parseable output contains only numbers
b) these numbers are equal or increased in each line
Since however this new item must be selected with the "list" argument
this shouldn't be a problem.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
A virtual guest my run in either "horiziontal" or "vertical" mode
which is the mode in which the underlying hypervisor schedules the
guest cpu.
Since this is of interest print this in the readable output.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The readable output prints also informations like cores per socket etc.
On newer kernel versions on s390 this information is available via
/proc/sysinfo. However it does not contain the layout of the guest but
the layout of the real machine.
Nevertheless this is better than random guessing with completely broken
numbers like we have it now on s390. If the information is not available
we fall back to old mechanism with more or less random numbers.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The fallback calculation of nthreads did not consider books.
In order to avoid division/multiply by/with zero make sure each number
used is at least "1".
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Completely virtualized architectures like s390 may have multiple
virtual sockets and/or cores where each of them has a different
number of cores and cpus.
So the general assumption within the allocation scheme that e.g.
each socket contains the same number of cores is not necessarily
true. To make sure the arrays are always large enough we simply
allocate enough memory so that each array could hold cpu masks
for all present cpus.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
... to allow define output columns, for example:
$ lscpu --parse=CPU,CORE,NODE,CACHE
# CPU,Core,Node,L1d:L1i:L2
0,0,0,0:0:0
1,1,0,1:1:0
Note that CPU caches are separated by ":" in the new format. The
output for --parse (without the list of the columns) is backwardly
compatible, it means:
$ lscpu --parse
# CPU,Core,Socket,Node,,L1d,L1i,L2
0,0,0,0,,0,0,0
1,1,0,0,,1,1,0
Signed-off-by: Karel Zak <kzak@redhat.com>
This patch adds support for books in cpu topology output. Books are
currently only present on the s390 architecture, however it looks like
others will follow to use the extra scheduling domain of the kernel.
Books are logically between sockets and nodes. In order to not break
any existing tools that might parse the output of lscpu the output
is changed so that books will follow nodes:
CPU,Core,Socket,Node,Book
In addition the readable output is changed from
"CPU socket(s):" to "Socket(s) per book:" or simply "Socket(s):" in the
absence of books.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
s390 has a "bogomips per cpu" string instead of a "bogomips" string in
/proc/sysinfo. So add a second bogomips lookup which detects the s390
variant.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>