Bugzilla – Bug 1214146
After upgrade from 15.4, only 1 thread per core is recognised
Last modified: 2023-08-11 09:57:07 UTC
Created attachment 868739 [details] view of KDE system monitor-->history I'm running OpenSUSE Leap 15.5 with all current updates on a workstation with a Xeon 14 core CPU and 28 threads. Previously, on 15.4, all 28 threads were being used e.g. when video rendering with Kdenlive, but now only 14 are shown as available, hence half the rendering speed. Looking in KInfo Centre, it lists the CPU as having only 1 thread per core, which is incorrect. neil@localhost:~> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 46 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 14 On-line CPU(s) list: 0-13 Vendor ID: GenuineIntel Model name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz CPU family: 6 Model: 63 Thread(s) per core: 1 Core(s) per socket: 14 Socket(s): 1 Stepping: 2 CPU max MHz: 3600.0000 CPU min MHz: 1200.0000 BogoMIPS: 5188.06 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts ac pi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfm on pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d Caches (sum of all): L1d: 448 KiB (14 instances) L1i: 448 KiB (14 instances) L2: 3.5 MiB (14 instances) L3: 35 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-13 Vulnerabilities: Itlb multihit: KVM: Mitigation: VMX unsupported L1tf: Mitigation; PTE Inversion Mds: Mitigation; Clear CPU buffers; SMT disabled Meltdown: Mitigation; PTI Mmio stale data: Mitigation; Clear CPU buffers; SMT disabled Retbleed: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, RSB filling, PBRSB-eIBRS Not affect ed Srbds: Not affected Tsx async abort: Not affected neil@localhost:~> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.12-default root=UUID=23dff492-d2ad-4bd9-8d4d-91a133d10143 apm=off a cpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf splash=si lent preempt=full mitigations=auto quiet security=apparmor
(In reply to Neil Lewis from comment #0) > neil@localhost:~> cat /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.12-default > root=UUID=23dff492-d2ad-4bd9-8d4d-91a133d10143 apm=off a > cpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux > psmouse.proto=bare irqpoll pci=nommconf splash=si > lent preempt=full mitigations=auto quiet security=apparmor You seem booting with acpi=off? It has many side effects.
Thanks! Yes, switching ACPI back on resulted in the system seeing all 28 threads available again. Simple as that :-)
OK, let's close.