mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Dhruva G <goledhruva@gmail.com>,
	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
Subject: Re: [PATCH v3 2/2] zstd: use cpu_feature_enabled() for in-kernel BMI2 dispatch
Date: Thu, 3 Sep 2026 11:53:21 +0100	[thread overview]
Message-ID: <5fa70fc4-9b01-4303-85f1-bcffbb877789@linux.dev> (raw)
In-Reply-To: <d1b78cdd-33f6-447c-8a0d-ce79fe1e6c28@gmail.com>



On 02/09/2026 18:40, Dhruva G wrote:
> Hi Usama,
> 
> On 01-09-2026 16:37, Usama Arif wrote:
>> Zstd's dynamic BMI2 implementation probes CPUID when a compression or
>> decompression context is initialized, stores the result in the context,
>> and tests that value at every dispatch site. In normal kernel builds this
>> bypasses the x86 feature policy and uses ordinary runtime branches instead
>> of allowing x86 alternatives to resolve the feature check at boot.
>>
>> Add ZSTD_USE_BMI2() and use it at every runtime BMI2/default selector. For
>> normal x86 kernel objects, the predicate expands directly to
>> cpu_feature_enabled(X86_FEATURE_BMI2). When dynamic BMI2 dispatch is not
>> available it is false; other builds retain the caller-provided flag. Keep
>> the existing HUF conditional layout because DYNAMIC_BMI2 also controls
>> whether target-attributed variants are emitted.
>>
>> Add the matching ZSTD_SET_BMI2() abstraction for context initialization.
>> Normal x86 kernel objects and builds without dynamic BMI2 do not cache CPU
>> state. Other builds with dynamic dispatch, including preboot, retain the
>> existing behavior. Keep the BMI2 members in the context structures so
>> their layouts do not change, and make the accessors return zero when
>> cached state is unused.
>>
>> Select the normal-kernel policy in zstd_deps.h. Builds which define
>> __DISABLE_EXPORTS, including the x86 preboot decompressor, retain the existing
>> CPUID-backed dispatch because the normal alternatives infrastructure is not
>> available there.
>>
>> A 4 KiB zstd-generic crypto_acomp benchmark in a one-vCPU KVM guest gave
>> these median results:
>>
>>                         Before      After     Change
>>   Compression      16,634 ns/op  13,394 ns/op  -19.5%
>>   Decompression     3,480 ns/op     963 ns/op  -72.3%
>>
>> Signed-off-by: Usama Arif <usama.arif@linux.dev>
>> ---
> 
> These comments still say BMI2 support is determined once per context:
> - lib/zstd/compress/zstd_compress_internal.h:473
> - lib/zstd/decompress/zstd_decompress_internal.h:159

Good catch! Thanks. I will change to:

Cached for per-context dispatch: 1 if the CPU supports BMI2, 0 otherwise.

> 
>>  lib/zstd/common/compiler.h                    | 12 ++++++++++++
>>  lib/zstd/common/entropy_common.c              | 12 ++++++------
>>  lib/zstd/common/fse_decompress.c              |  7 ++++---
>>  lib/zstd/common/zstd_deps.h                   |  5 +++++
>>  lib/zstd/compress/huf_compress.c              |  6 +++++-
>>  lib/zstd/compress/zstd_compress.c             | 12 ++++++------
>>  lib/zstd/compress/zstd_compress_internal.h    |  9 +++++++++
>>  lib/zstd/compress/zstd_compress_sequences.c   |  8 +++++---
>>  lib/zstd/compress/zstd_compress_superblock.c  |  2 +-
>>  lib/zstd/decompress/huf_decompress.c          | 18 +++++++++---------
>>  lib/zstd/decompress/zstd_decompress.c         |  4 +---
>>  lib/zstd/decompress/zstd_decompress_block.c   | 19 +++++++------------
>>  .../decompress/zstd_decompress_internal.h     |  2 +-
>>  13 files changed, 71 insertions(+), 45 deletions(-)
>>
>> diff --git a/lib/zstd/common/compiler.h b/lib/zstd/common/compiler.h
>> index dc9bd15e174e9..47f6c0372c58c 100644
>> --- a/lib/zstd/common/compiler.h
>> +++ b/lib/zstd/common/compiler.h
>> @@ -14,6 +14,7 @@
>>  
>>  #include <linux/types.h>
>>  
>> +#include "zstd_deps.h"
>>  #include "portability_macros.h"
>>  
>>  /*-*******************************************************
>> @@ -96,6 +97,17 @@
>>   */
>>  #define BMI2_TARGET_ATTRIBUTE TARGET_ATTRIBUTE("lzcnt,bmi,bmi2")
>>  
>> +#if !DYNAMIC_BMI2
>> +#  define ZSTD_USE_BMI2(bmi2) 0
>> +#  define ZSTD_SET_BMI2(state, value) do { } while (0)
>> +#elif defined(ZSTD_USE_KERNEL_CPU_FEATURES)
>> +#  define ZSTD_USE_BMI2(bmi2) cpu_feature_enabled(X86_FEATURE_BMI2)
> 
> Here, we do not include <asm/cpufeature.h>. Instead, every current .c user includes that header separately.
> This works today, but it maybe fragile: the next user of ZSTD_USE_BMI2() can fail to compile unless they know
> about this hidden requirement. 
> Do you think perhaps we should provide that here in this header itself?

I tried that, but compiler.h is included by unrelated zstd translation units.
On x86, <asm/cpufeature.h> eventually includes <asm/current.h>, which defines
current as get_current(). This breaks the existing local variable named current 
in zstd_double_fast.c.

I think the current apporach is ok?

> 
> With that, feel free to add
> 
> Reviewed-by: Dhruva Gole <goledhruva@gmail.com>

Thanks for the review!



      reply	other threads:[~2026-09-03 10:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 11:07 [PATCH v3 0/2] zstd: use x86 feature infrastructure for " Usama Arif
2026-09-01 11:07 ` [PATCH v3 1/2] lib/zstd: add fallback aliases for disabled BMI2 variants Usama Arif
2026-09-03 12:35   ` Dhruva G
2026-09-01 11:07 ` [PATCH v3 2/2] zstd: use cpu_feature_enabled() for in-kernel BMI2 dispatch Usama Arif
2026-09-02 17:40   ` Dhruva G
2026-09-03 10:53     ` Usama Arif [this message]

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=5fa70fc4-9b01-4303-85f1-bcffbb877789@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=chengming.zhou@linux.dev \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=goledhruva@gmail.com \
    --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

all inboxes | Powered by JetHome®