mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Eric Biggers <ebiggers@kernel.org>
Cc: dsterba@suse.com, linux-kernel@vger.kernel.org, terrelln@fb.com,
	linux-crypto@vger.kernel.org, yosry@kernel.org,
	hannes@cmpxchg.org, nphamcs@gmail.com, chengming.zhou@linux.dev,
	shakeel.butt@linux.dev, kernel-team@meta.com
Subject: Re: [PATCH 0/3] zstd: probe the CPU for BMI2 support once, not per context
Date: Thu, 27 Aug 2026 15:21:44 +0100	[thread overview]
Message-ID: <c8d71171-9b4c-418a-a48d-c18bb20da52f@linux.dev> (raw)
In-Reply-To: <20260827023943.GA2327@sol>



On 27/08/2026 03:39, Eric Biggers wrote:
> On Wed, Aug 26, 2026 at 05:25:35AM -0700, Usama Arif wrote:
>> zstd picks between BMI2 and generic code paths at runtime, and issues
>> CPUID to decide every time a compression or decompression context is set
>> up. The answer cannot change while the kernel is running.
>>
>> It is not a cold path: squashfs calls zstd_init_dstream() for every block
>> it decompresses, and erofs, btrfs, f2fs and crypto/zstd all initialise a
>> context per operation. Each probe is two serializing CPUID instructions
>> on x86.
>>
>> Patch 1 routes ZSTD_initStaticCCtx() through ZSTD_cpuSupportsBmi2()
>> instead of open-coding the probe, which also fixes it testing for BMI2
>> without BMI1 - the bodies it selects are tagged
>> TARGET_ATTRIBUTE("lzcnt,bmi,bmi2"), so both are needed. No CPU in the
>> field implements BMI2 without BMI1, so this is latent. Patch 2 skips the
>> probe when DYNAMIC_BMI2 is 0, where every consumer ignores the flag
>> anyway. Patch 3 caches the result.
>>
>> A 4 KiB crypto_acomp benchmark [1] in a one-vCPU KVM guest, twelve boots
>> of nine 30,000-operation rounds, median per-round mean over 108 rounds:
>>
>>                     compress     decompress
>>   unpatched         16,756 ns     3,455 ns
>>   patched           13,646 ns     1,002 ns
>>                     -3,110 ns    -2,452 ns
>>                      (18.6%)      (71.0%)
>>
>> The main reason is because CPUID is an unconditional VM exit.
>>
>> [1] https://gist.github.com/uarif1/5cf02f0e22c23f0d1b3d84348f12914c
>>  
>> Usama Arif (3):
>>   zstd: use ZSTD_cpuSupportsBmi2() in ZSTD_initStaticCCtx()
>>   zstd: skip the BMI2 probe when dynamic BMI2 dispatch is disabled
>>   zstd: probe the CPU for BMI2 support only once
>>
>>  lib/zstd/common/zstd_internal.h   | 22 ++++++++++++++++++++--
>>  lib/zstd/compress/zstd_compress.c |  2 +-
>>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> Why not just use cpu_feature_enabled(X86_FEATURE_BMI2), which compiles
> down to a static branch?  All these issues are caused by lib/zstd/ using
> its own custom CPU feature detection code, instead of the normal CPU
> feature detection code that the rest of the kernel uses.
> 
> - Eric


The only issue I saw with that was that zstd is a standalone library that
is imported, so I am not sure how using cpu_feature_enabled() would work
for the maintainers. If the maintainers are happy with it, I think the
below patch is much better.


From 0b21d945f579cbb5e41b92b4c9306e9d5bac84f1 Mon Sep 17 00:00:00 2001
From: Usama Arif <usama.arif@linux.dev>
Date: Thu, 27 Aug 2026 05:34:41 -0700
Subject: [PATCH] zstd: use kernel CPU feature detection on x86

Zstd currently probes CPUID while initializing each compression or
decompression context. This bypasses the x86 feature policy used by the
rest of the kernel and repeats a serializing instruction sequence for
every context.

Use cpu_feature_enabled() in the normal x86 compressor and decompressor
objects. Check ABM, BMI1, and BMI2 because the dispatched functions are
compiled with lzcnt, bmi, and bmi2. The checks are alternatives-patched
at boot.

The effect is especially visible under virtualization, where CPUID
normally causes a VM exit. A 4 KiB crypto_acomp benchmark was run in
one-vCPU KVM guests. Comparing the unpatched baseline with this
three-patch series, the median reported ns/op values were:

                         before    after
  compression            16,777   13,635 ns/op  (-18.7%)
  decompression           3,454    1,006 ns/op  (-70.9%)

Keep the existing raw CPUID fallback for preboot and other builds which
cannot use the normal x86 feature infrastructure. Also retain the early
return when dynamic dispatch is disabled.

Signed-off-by: Usama Arif <usama.arif@linux.dev>
---
 lib/zstd/Makefile               |  5 +++++
 lib/zstd/common/zstd_internal.h | 18 ++++++++++++++----
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/lib/zstd/Makefile b/lib/zstd/Makefile
index be218b5e0ed59..db1d1439f5447 100644
--- a/lib/zstd/Makefile
+++ b/lib/zstd/Makefile
@@ -42,3 +42,8 @@ zstd_common-y := \
 		common/error_private.o \
 		common/fse_decompress.o \
 		common/zstd_common.o \
+
+ifeq ($(CONFIG_X86),y)
+CFLAGS_compress/zstd_compress.o += -DZSTD_USE_KERNEL_CPU_FEATURES
+CFLAGS_decompress/zstd_decompress.o += -DZSTD_USE_KERNEL_CPU_FEATURES
+endif
diff --git a/lib/zstd/common/zstd_internal.h b/lib/zstd/common/zstd_internal.h
index 41f190b533209..f7d3bca650747 100644
--- a/lib/zstd/common/zstd_internal.h
+++ b/lib/zstd/common/zstd_internal.h
@@ -31,6 +31,11 @@
 #include "fse.h"
 #include "huf.h"
 #include <linux/xxhash.h>                /* XXH_reset, update, digest */
+
+/* Use the kernel's CPU feature policy in normal x86 kernel builds. */
+#if defined(ZSTD_USE_KERNEL_CPU_FEATURES)
+#include <asm/cpufeature.h>
+#endif
 #define ZSTD_TRACE 0
 
 /* ---- static assert (debug) --- */
@@ -311,12 +316,17 @@ size_t ZSTD_decodeSeqHeaders(ZSTD_DCtx* dctx, int* nbSeqPtr,
  */
 MEM_STATIC int ZSTD_cpuSupportsBmi2(void)
 {
-#if DYNAMIC_BMI2
-    ZSTD_cpuid_t cpuid = ZSTD_cpuid();
-    return ZSTD_cpuid_bmi1(cpuid) && ZSTD_cpuid_bmi2(cpuid);
-#else
+#if !DYNAMIC_BMI2
     /* Nothing looks at the flag in this configuration. */
     return 0;
+#elif defined(ZSTD_USE_KERNEL_CPU_FEATURES)
+    return cpu_feature_enabled(X86_FEATURE_ABM) &&
+           cpu_feature_enabled(X86_FEATURE_BMI1) &&
+           cpu_feature_enabled(X86_FEATURE_BMI2);
+#else
+    ZSTD_cpuid_t cpuid = ZSTD_cpuid();
+    return ZSTD_cpuid_bmi1(cpuid) &&
+           ZSTD_cpuid_bmi2(cpuid);
 #endif
 }
 
-- 
2.53.0-Meta



  reply	other threads:[~2026-08-27 14:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 12:25 Usama Arif
2026-08-26 12:25 ` [PATCH 1/3] zstd: use ZSTD_cpuSupportsBmi2() in ZSTD_initStaticCCtx() Usama Arif
2026-08-26 12:25 ` [PATCH 2/3] zstd: skip the BMI2 probe when dynamic BMI2 dispatch is disabled Usama Arif
2026-08-26 12:25 ` [PATCH 3/3] zstd: probe the CPU for BMI2 support only once Usama Arif
2026-08-26 17:10 ` [PATCH 0/3] zstd: probe the CPU for BMI2 support once, not per context Nhat Pham
2026-08-27  2:39 ` Eric Biggers
2026-08-27 14:21   ` Usama Arif [this message]
2026-08-28 20:19 Linus Torvalds

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=c8d71171-9b4c-418a-a48d-c18bb20da52f@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=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

all inboxes | Powered by JetHome®