Developers submitted two optimization patches for zswap, and the page read latency in specific tests dropped significantly.

Abstract:

Linux developer Osama Arif submitted two patches to the kernel mailing list aimed at reducing request contention when zswap loads swap pages. Zswap is the compression cache mechanism of Linux. It compresses the pages to be swapped out and temporarily stores them in the memory. If the pages can be read from the compression cache, access to the swap device can be reduced, which is especially helpful for alleviating disk I/O pressure when memory is tight.

The problem is that the existing code makes compressed writes and compressed reads share asynchronous per-CPU compression requests and mutex locks. If a low-priority write task is preempted during the lock period, a high-priority read task may also be forced to wait. The first patch sets requests, wait objects, and mutex locks for compression and decompression respectively, so that reading is no longer blocked by writing tasks; the second patch allows the synchronous software compression algorithm to use on-stack requests to further bypass the zswap lock. Algorithms that require asynchronous processing or additional request context still use per-CPU requests and mutex locks.

Benchmark tests published by the patch author show that in a single virtual CPU environment, the median slowest read latency per round dropped from 22.3 milliseconds to 0.97 milliseconds; in an 8 virtual CPU environment, it dropped from 314 milliseconds to 7 milliseconds. Each test was run for 5 rounds, using zstd compressor, virtual machine and memory disk as switching devices, and creating load through different priority tasks; the number of reads exceeding 10 milliseconds was also reduced from 26 to 35 times per round in a single core to zero, and in a multi-core environment it was reduced from 3 to 18 times per round to a maximum of one time. The authors state that benchmarks and test programs are written with the help of large language models.

These numbers reflect read latency improvements in specific stress tests and do not mean that all Linux devices or daily workloads will see the same overall speedup.

The patch is still in the kernel mailing list review stage and has not yet been merged into the mainline kernel:

https://lore.kernel.org/lkml/

[email protected]