Closed issue by ahesford on void-packages repository https://github.com/void-linux/void-packages/issues/18940 Description: I'm opening this issue to start a discussion about switching the generic kernel config from full PREEMPT to PREEMPT_VOLUNTARY. The kernel configuration documents suggest using PREEMPT for a low-latency desktop and disabling preemption for a server. The suggested use case for PREEMPT_VOLUNTARY is just a "desktop". PREEMPT_VOLUNTARY adds explicit preemption points in the kernel that allow syscalls to be interrupted [[1]](https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re152.html). Full PREEMPT takes this a step further by allowing interruption between the explicit points. This comes at the cost of runtime overhead and a corresponding reduction in processing throughput [[2]](https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re153.html). The desired effect of these options is to make the system appear more responsive by interrupting other tasks more frequently. There is an objective reason for favoring the switch in the near term; the ZFS kernel module attempts to use preemptible RCU symbols when PREEMPT is configured in the kernel, and these symbols have been marked GPL-only for Linux 5.5. The ZFS modules installed by the Void package will not build against 5.5. When PREEMPT_VOLUNTARY is configured, the kernel uses TREE_RCU instead of PREEMPT_RCU, and the ZFS modules build as expected. In the long term, I expect the ZoL crowd will fix the compatibility and this motivation will be moot. The remaining question is whether PREEMPT_VOLUNTARY is a more generic option for the stock Void kernel. Attempting to answer this question probably amounts to fighting a holy war. Nevertheless, there may be value in asking it. I've been asked to provide some benchmarks (e.g., Phoronix Test Suite) to support the proposed switch. To meaningfully measure the tradeoff between latency and throughput as a result of the change in preemption configuration will be difficult or impossible. In any case, the benchmarks will almost certainly favor a particular use case that may or may not be relevant to any specific user. Some people have tried; see [this Raspberry Pi discussion](https://github.com/raspberrypi/linux/issues/1216) that includes some simple timing tests, or [this benchmark using cyclictest and sockperf](https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html). Other distributions use a variety of defaults: 1. Like Void, [Arch Linux](https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux) uses PREEMPT and a 1000 Hz tick. 2. Ubuntu uses PREEMPT_VOLUNTARY with a 250 Hz tick. Ubuntu also offers alternative kernel packages with different preemption models. 3. The aforementioned Raspberry Pi discussion indicates that their default is PREEMPT_VOLUNTARY with a 100 Hz tick. 4. [Debian](https://packages.debian.org/sid/kernel/linux-config-5.4), like Ubuntu, uses PREEMPT_VOLUNTARY with a 250 Hz tick. As PREEMPT_VOLUNTARY seems to be a tradeoff between throughput and latency, it seems like a prime candidate for generic kernel configs, where the intended audience will have diverse needs and may not be best served by the fully preemptible kernel. Whether the tick rate should be reduced from 1000 Hz to a lower value is a separate issue.