Linux LZ4 resync to v1.10.0 lifts decompression up to 21%

Samsung engineer Michal Wilczynski posted a 9-patch series on September 25, 2026 that brings the Linux kernel's LZ4 compression code up to date with upstream LZ4 v1.10.0. The kernel's copy is 488 upstream commits behind. The update speeds up decompression at every block size tested, by up to 21%, and it closes a safety gap in the old code.

LZ4 is a compression format built for speed rather than small files. The kernel uses it where data must be packed and unpacked constantly, such as compressed memory and read-only file systems.

How far behind the kernel's LZ4 is

The kernel does not load LZ4 as an outside library. It carries its own copy of the code in its source tree, and that copy has drifted. According to Wilczynski's cover letter, the two halves are frozen at different points.

Part	Version in the kernel	From
Decompressor	LZ4 v1.8.3	2018
Compressor	LZ4 v1.7.3	2017
Upstream target	LZ4 v1.10.0	July 22, 2024

The upstream project released v1.10.0 on July 22, 2024, calling it the "Multicores edition". Its release notes say it folds in more than 600 commits. Its headline feature is multithreaded compression, and it also promotes dictionary compression to stable.

The bounds-check problem

The strongest argument in the cover letter is about safety, not speed. The kernel's forked LZ4_decompress_fast() function never checks whether it is writing inside its buffer. "The forked LZ4_decompress_fast() has no bounds checks, so corrupted input runs off the output buffer in both directions," Wilczynski wrote.

A bounds check is a test that stops code from reading or writing past the end of a block of memory. Without one, damaged or hostile compressed data can make the decompressor write over unrelated memory. That is the classic path to a crash or a security hole. The resync replaces the forked code with upstream's version.

The speed and size trade-off

The cover letter reports faster decompression at every block size it tested, from 4K to 256K. The gains for the LZ4 library itself were:

• 4K blocks: 11% faster
• 16K blocks: 21% faster, the largest gain
• 64K blocks: 17% faster
• 256K blocks: 10% faster

Tests through EROFS, a read-only file system, showed 11% at 4K and 14% at 64K.

The cost is size. On x86_64 the compiled code grows from 45K to 89K. The cover letter puts most of that down to upstream's more complete parser.

The series also changes how the code is maintained. The kernel would carry upstream's files as they are, instead of a hand-edited fork. "A re-sync becomes a directory copy," Wilczynski wrote.

What this means for developers

Check whether you use LZ4 in the kernel at all. The cover letter names four users: zram, erofs, f2fs and lib/decompress_unlz4. zram is a compressed swap device that lives in RAM. EROFS is a read-only file system, and F2FS is a file system designed for flash storage.

If you run zram with LZ4, this is the change most likely to reach you. Swapping to zram happens under memory pressure, when every CPU cycle counts. A double-digit decompression gain there can show up as a more responsive system. Run cat /sys/block/zram0/comp_algorithm to see which algorithm your zram device uses.

If you ship images on EROFS, the 11-14% gain applies to reading files. That likely matters most when many small blocks are read at once, such as at boot. Benchmark on your own hardware before counting on it, since the cover letter's figures come from its own test setup.

If you build for tiny devices, note the 44K growth in code size. On an embedded kernel with a tight flash budget, that is worth measuring.

Treat the bounds-check fix as the real reason to want this. Any path that decompresses data from disk or the network with the old fast decoder trusts its input completely. Until the series lands, prefer the checked decompression functions in your own kernel code.

This is a patch series under review, not merged code. Watch the linux-kernel list for maintainer replies, which will decide when it reaches a release.