Linux kernel developer Usama Arif identified that the in-kernel Zstd compression code was redundantly re-probing CPU support for BMI2 instructions on every single context creation, using two costly serializing CPUID instructions each time. Because filesystems like SquashFS call this per decompressed block, and EROFS, Btrfs, F2FS, and crypto/zstd call it per operation, the overhead was significant. Three patches now sent to the Linux kernel mailing list probe BMI2 support only once, yielding a 71% reduction in decompression time and an 18% reduction in compression time in crypto_acomp benchmarks. The patches are currently under review.
Questions this post answers
Why is in-kernel Zstd decompression so slow in Linux, and can it be fixed?
The in-kernel Zstd code re-probes whether the CPU supports BMI2 instructions every time a compression or decompression context is created, using two costly serializing CPUID instructions with unconditional VM exits. Since filesystems like SquashFS call this per block and EROFS, Btrfs, F2FS, and crypto/zstd call it per operation, this becomes a very hot code path. Patches submitted by Usama Arif probe BMI2 support once instead, yielding a 71% reduction in decompression time and an 18% reduction in compression time in crypto_acomp benchmarks. daily.dev surfaces kernel performance patches like this one for engineers tuning filesystem compression paths.