Low Latency Kernel

Tutorials & Guides
1

Anyone else running the low latency kernel?

uname -a
Linux HP-Laptop 5.15.0-58-lowlatency #64~20.04.1-Ubuntu SMP PREEMPT Fri Jan 6 18:45:25 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

It's the same kernel version as the generic kernel I was using before (newer kernels don't support ZFS sufficiently yet), but:

  1. Boot is a bit faster (except for ZFS pool importing is a bit slower).

  2. The CPU usage is a bit lower, so the CPU idles at a lower temperature.

  3. Applications open a bit faster, notably SRWare Iron opened in about 3/4th the time of the generic kernel, and there's none of the very, very slight keyboard lag of the generic kernel when typing my password into websites.

I think that's because the low latency kernel threads IRQs by default, so they can be preempted; dynamic preemption is enabled throughout the kernel:
grep PREEMPT_DYNAMIC /boot/config-$(uname -r)
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
... and that dynamic preemption improves throughput!

Table 1. Throughput Test: dbench Runs

Kernel Throughput
2.5.2 24.3813 MB/s
2.5.2-preempt 28.5920 MB/s

The timer frequency is also higher (1000 Hz vs. 250 Hz for generic); so with a many-core CPU, everything just works better. As CPUs gain more cores, the context-switching cost per core goes down, so naturally throughput increases as compared to lower core-count CPUs.

All-around, it just feels more responsive and quicker.

1 Like
2

Nope. I haven't. This is something I've learned just now reading this thread.

3

Sorry, I decided to run the 6.2.7 kernel, generic. My system sees no difference in performance using the standard or low latency (have used low latency in the past).

4

Another little bump in performance:
sudo apt install rtirq-init

In /etc/default/rtirq:
Change: RTIRQ_NON_THREADED="rtc snd"
To: RTIRQ_NON_THREADED="rtc"

Change: RTIRQ_NAME_LIST="snd usb i8042"
To: RTIRQ_NAME_LIST="ACP_PDM_IRQ snd_hda_intel snd_pci_acp3x snd_rn_pci_acp3x snd_pci_acp5x snd_pci_acp6x snd usb i8042"

You find what to put in the line above by issuing sudo lspci -v, noting the IRQs used by the sound system components, then issuing cat /proc/interrupts and using the text in the right-hand column for each of those IRQs.

If you don't do the immediately above, it will appear to work as long as you have the Settings window open (and with the focus) to the Bluetooth tab, but as soon as you close the Settings window, it'll start stuttering again. Doing the immediately above gives the IRQs used by the sound system components the highest priority, so they can be serviced by the CPU in a timely manner, no matter if the Bluetooth Settings window is open or not.

In Grub:
GRUB_CMDLINE_LINUX_DEFAULT="threadirqs preempt=full tsc=reliable numa=on nosmt=force nohz=1-5 rcu_nocbs=1-5"

I added the threadirqs kernel parameter, which changes the interrupt handlers to run in a threaded context. While the low-latency kernel does thread interrupts, it doesn't thread the interrupts related to sound. By forcing the sound system to use threaded interrupts (and giving those IRQs higher priority), we force guaranteed servicing of the sound system threads within a specified time.

This helps especially if you've got your phone connected via Bluetooth to your computer, and your headphones connected via Bluetooth to your computer, and you're listening to podcasts from your phone, through your computer, to your headphones (so you can hear your phone and your computer in the headphones)... without threadirqs and rtirq-init, the sound is choppy, no matter what setting I use for the CPU performance (I can peg all the cores to maximum frequency and the sound will still be choppy)... but with those added, it was only choppy very occasionally.

To fix that last bit of choppiness, I changed:
sudo sh -c "echo 10 > /sys/devices/system/cpu/cpufreq/conservative/down_threshold"

I decreased the CPU load at which the CPU will throttle down (previously 50).

sudo sh -c "echo 20 > /sys/devices/system/cpu/cpufreq/conservative/up_threshold"

I decreased the CPU load at which the CPU will throttle up (previously 99).

sudo sh -c "echo 10 > /sys/devices/system/cpu/cpufreq/conservative/freq_step"

I increased by how much the CPU frequency increases per step (previously 1).

5

Additional information: