Xeon CPU with 2 threads per core, but only 1 thread per core available since update from 15.4 to 15.5

English Hardware
1

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 Leap 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.

I guess there’s a system tweak for this, but does anyone know where exactly?

2

@neillewis23 Hi and welcome to the Forum :smile:
Can you show the output from the following commands;

lscpu
cat /proc/cmdline

You haven’t been into the system BIOS lately to make any adjustments?

3

Hi Malcolm, thanks for the suggestions.

No, I haven’t been into the BIOS, and the change from 15.4 to 15.5 was done via an upgrade rather than a fresh install, so I didn’t manually change any config scripts.

Here’s the outputs you requested:

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
4

Please, in the future post computer text as preformatted (button </> in editor).

P.S. looking more closely, it probably just shows the current state of SMT; as far as I understand, default mitigations do not automatically disable it.

5

@neillewis23 Can you check the system BIOS to see if something has disabled SMT?

I have (On Tumbleweeed though) with virtualization enabled in the BIOS

...
CPU(s):                  36
  On-line CPU(s) list:   0-35
Vendor ID:               GenuineIntel
Model name:            Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz
...
Thread(s) per core:  2
    Core(s) per socket:  18
    Socket(s):           1
....
ulnerabilities:         
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
  Mds:                   Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown:              Mitigation; PTI
  Mmio stale data:       Mitigation; Clear CPU buffers; SMT vulnerable
  Retbleed:              Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Mitigation; Clear CPU buffers; SMT vulnerable

I don’t think any of the boot options should affect SMT…

6

Can you boot Leap 15.4 live image and check? Also, if SMT is possible but disabled by kernel you should see SMT: Disabled (or SMT: Force disabled) in kernel log. If these messages are not present, most likely SMT is disabled by BIOS.

1 Like
7

Solution was provided, thank you all. It seems that, during installation, acpi was switched off during boot. Re-enabling that resulted in all 28 threads being available again.

8

Actually, your kernel options look more like failsafe menu entry.