From: Usama Arif <usama.arif@linux.dev>
To: dsterba@suse.com, linux-kernel@vger.kernel.org, terrelln@fb.com,
terrelln@meta.com, linux-crypto@vger.kernel.org,
yosry@kernel.org, ebiggers@kernel.org,
torvalds@linux-foundation.org
Cc: hannes@cmpxchg.org, nphamcs@gmail.com, chengming.zhou@linux.dev,
shakeel.butt@linux.dev, kernel-team@meta.com,
Usama Arif <usama.arif@linux.dev>
Subject: [PATCH v2 0/2] zstd: use x86 feature infrastructure for BMI2 dispatch
Date: Sun, 30 Aug 2026 15:20:23 -0700 [thread overview]
Message-ID: <20260830222100.2706175-1-usama.arif@linux.dev> (raw)
Zstd currently probes CPUID whenever a compression or decompression
context is initialized, stores the result in the context, and tests that
value at each BMI2 dispatch site. For normal x86 kernel builds this
duplicates the kernel's CPU feature infrastructure, bypasses its feature
policy, and leaves an ordinary runtime test in the dispatch path.
Use cpu_feature_enabled(X86_FEATURE_BMI2) directly at the dispatch sites
for normal x86 kernel objects. This uses the x86 alternatives-backed
static CPU feature mechanism, allowing the feature test to be resolved at
boot instead of loading and testing a value stored in each context.
ZSTD_USE_BMI2() keeps the other build modes working as before. It expands
to the caller-provided flag for standalone builds and to false when
DYNAMIC_BMI2 is disabled. The x86 preboot decompressor is built outside
lib/zstd/Makefile, so it continues to use Zstd's raw CPUID detection.
Patch 1 adds aliases from BMI2 function names to their default
implementations when the BMI2 variants are not compiled. This is a
no-functional-change preparation: after patch 2 removes the affected
selector-level preprocessor guards, the compiler must still resolve the
function named in an if (0) branch before eliminating it.
Patch 2 adds ZSTD_USE_BMI2(), converts the runtime selectors, and avoids
Zstd's private CPUID probes in normal x86 kernel objects. The BMI2 members
remain in the context structures so their layouts do not change.
A 4 KiB zstd-generic crypto_acomp benchmark [1] in a one-vCPU KVM guest
gave these median results:
Before After Change
Compression 16,634 ns 13,394 ns -19.5%
Decompression 3,480 ns 963 ns -72.3%
The improvement is especially large in a guest because raw CPUID causes
a VM exit.
[1] https://gist.github.com/uarif1/5cf02f0e22c23f0d1b3d84348f12914c
v1 -> v2: https://lore.kernel.org/all/20260826122558.2662013-1-usama.arif@linux.dev/
- Replace the proposed cached feature value with cpu_feature_enabled(X86_FEATURE_BMI2)
at each dispatch site. (Eric Biggers and Linus Torvalds)
- Check only X86_FEATURE_BMI2 instead of BMI1, BMI2, and ABM. (Linus Torvalds)
- Split the fallback aliases into a separate no-functional-change patch.
Usama Arif (2):
lib/zstd: add fallback aliases for disabled BMI2 variants
zstd: use cpu_feature_enabled() for in-kernel BMI2 dispatch
lib/zstd/Makefile | 1 +
lib/zstd/common/compiler.h | 8 +++++
lib/zstd/common/entropy_common.c | 16 ++++++----
lib/zstd/common/fse_decompress.c | 9 ++++--
lib/zstd/compress/huf_compress.c | 7 +++-
lib/zstd/compress/zstd_compress.c | 12 ++++---
lib/zstd/compress/zstd_compress_internal.h | 9 ++++++
lib/zstd/compress/zstd_compress_sequences.c | 12 +++++--
lib/zstd/compress/zstd_compress_superblock.c | 2 +-
lib/zstd/decompress/huf_decompress.c | 23 +++++++------
lib/zstd/decompress/zstd_decompress.c | 4 +++
lib/zstd/decompress/zstd_decompress_block.c | 32 ++++++++++++-------
.../decompress/zstd_decompress_internal.h | 2 +-
13 files changed, 97 insertions(+), 40 deletions(-)
base-commit: 4b18edbd8e70f7e6860d56370f13244896d0f95c
--
2.53.0-Meta
next reply other threads:[~2026-08-30 22:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 22:20 Usama Arif [this message]
2026-08-30 22:20 ` [PATCH v2 1/2] lib/zstd: add fallback aliases for disabled BMI2 variants Usama Arif
2026-08-30 22:20 ` [PATCH v2 2/2] zstd: use cpu_feature_enabled() for in-kernel BMI2 dispatch Usama Arif
2026-08-30 23:06 ` Linus Torvalds
2026-08-31 12:09 ` Usama Arif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830222100.2706175-1-usama.arif@linux.dev \
--to=usama.arif@linux.dev \
--cc=chengming.zhou@linux.dev \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nphamcs@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=terrelln@fb.com \
--cc=terrelln@meta.com \
--cc=torvalds@linux-foundation.org \
--cc=yosry@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox