---
title: "Patches Provide For Much Faster In-Kernel Zstd Due To Embarrassingly Bad Inefficiency"
url: https://daily.dev/posts/patches-provide-for-much-faster-in-kernel-zstd-due-to-embarrassingly-bad-inefficiency-zshp9rw2o
source_url: https://www.phoronix.com/news/In-Kernel-Zstd-BMI2-Probing
type: article
source: "Phoronix"
published: 2026-08-26T20:01:38.046Z
updated: 2026-08-26T20:02:19.568Z
tags: ["linux", "performance", "filesystems"]
reading_time: 2
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Patches Provide For Much Faster In-Kernel Zstd Due To Embarrassingly Bad Inefficiency

**[Phoronix](https://daily.dev/sources/phoronix)** · 2 min read · 0 upvotes · 0 comments

## Summary

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.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.phoronix.com/news/In-Kernel-Zstd-BMI2-Probing>

## 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._

## Similar posts on daily.dev

- [New Patch Can Boost Linux ZRAM Compression Performance By Over 50%](https://daily.dev/posts/new-patch-can-boost-linux-zram-compression-performance-by-over-50--knp4luhhe) · Phoronix · 0 upvotes · 0 comments
- [SquashFS Optimization Achieves 15,277x Performance In Developer Benchmark](https://daily.dev/posts/squashfs-optimization-achieves-15-277x-performance-in-developer-benchmark-tj8odgbxz) · Phoronix · 1 upvotes · 0 comments
- [Linux Patches To Unconditionally Enable Architecture-Optimized BLAKE2s Support](https://daily.dev/posts/linux-patches-to-unconditionally-enable-architecture-optimized-blake2s-support-yvfzlvxmk) · Phoronix · 0 upvotes · 0 comments

---

Tags: [#linux](https://daily.dev/tags/linux), [#performance](https://daily.dev/tags/performance), [#filesystems](https://daily.dev/tags/filesystems)

[View this post on daily.dev](https://daily.dev/posts/patches-provide-for-much-faster-in-kernel-zstd-due-to-embarrassingly-bad-inefficiency-zshp9rw2o)
