Bug 1214146 - After upgrade from 15.4, only 1 thread per core is recognised
Summary: After upgrade from 15.4, only 1 thread per core is recognised
Status: RESOLVED INVALID
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Leap 15.5
Hardware: x86-64 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: openSUSE Kernel Bugs
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-10 08:30 UTC by Neil Lewis
Modified: 2023-08-11 09:57 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
view of KDE system monitor-->history (134.76 KB, image/jpeg)
2023-08-10 08:30 UTC, Neil Lewis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Lewis 2023-08-10 08:30:41 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
Comment 1 Takashi Iwai 2023-08-10 10:25:52 UTC
(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.
Comment 2 Neil Lewis 2023-08-11 09:04:28 UTC
Thanks! Yes, switching ACPI back on resulted in the system seeing all 28 threads available again. Simple as that :-)
Comment 3 Takashi Iwai 2023-08-11 09:57:07 UTC
OK, let's close.