split lock detection trap issue effecting PVE performance?

[triks]

Slightly concerned about this in logs, research indicates it could lead to performance issues in Proxmox. Is this an isolated issue I am having or a broader issue? Im reluctant to edit my GRUB to disable it with #Disable with split_lock_detect=off.

Apr 08 18:12:43 pve kernel: x86/split lock detection: #AC: CPU 1/KVM/4784 took a split_lock trap at address: 0x7ef1b050
Apr 08 18:12:43 pve kernel: x86/split lock detection: #AC: CPU 2/KVM/4785 took a split_lock trap at address: 0x7ef1b050
Apr 08 18:12:43 pve pvesh[1234]: Waiting for 20 seconds (startup delay)

/etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on i915.enable_psr=0 i915.enable_fbc=0 i915.lvds_downclock=1 pci=realloc"
GRUB_CMDLINE_LINUX=""

 

[cheiss]

Hi,

please see our dedicated wiki article on this: Split-lock detection

 

[triks]

didn't realise it was a thing.
thx I'll give it a go.

 

[triks]

seeing this so I guess I should take the risk and disable it? Looks like pfsense VM is triggering it which is kind of strange as that is a very light load.

root@pve:~# bpftrace -e 'kfunc:vmlinux:split_lock_warn /0<*(uint32*)kaddr("sysctl_sld_mitigate")/{time("%H:%M:%S: "); printf("slowing down %s (pid=%d) for >10ms\n", comm, pid);}' Attaching 1 probe... 19:48:19: slowing down CPU 0/KVM (pid=4706) for >10ms 19:50:37: slowing down CPU 0/KVM (pid=4706) for >10ms 19:52:47: slowing down CPU 0/KVM (pid=4706) for >10ms

root@pve:~# ps -p 4706 -o cmd
CMD
/usr/bin/kvm -id 202 -name win11-01,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/q

kernel 6.8.12-9-pve

 

[cheiss]

seeing this so I guess I should take the risk and disable it?

Well, as mentioned in the last section of the linked wiki article - this entirely depends on your workload and what runs inside your guests.

Preferably of course would be to fix the actual in-guest process performing these split-locks.
If you only run code inside the guest you fully trust, you may consider disabling the detection. Disabling this detection/mitigation is a security trade-off, at the end of the day, so should be done with care only.

 

[triks]

I get it, I found this also helpful as I am in the same boat.
thx again.

"Newer Intel CPUs have performance and efficiency cores - 2 different varieties of core on the same die. All the machines I run are slightly older and have all the same type of core."