The August 26 proposal to avoid repeated BMI2 probes evolved into a revised patch on August 30. It now uses the kernel’s x86 feature machinery directly. The reported performance gain concerns small operations in a one-vCPU KVM guest.
The proposal changed after review
The initial series proposed caching a CPU-feature answer. The revised series instead uses cpu_feature_enabled(X86_FEATURE_BMI2) for normal kernel builds. This avoids private CPUID probing and lets the kernel resolve the dispatch through its existing feature mechanism.
Standalone and preboot builds have different constraints; the proposal retains their separate paths. It is therefore inaccurate to say every copy of Zstd now detects the CPU once in the same way. This article describes the posted revision and does not establish its delivery in a distribution package.
What the measured percentage refers to
The contributor reports a 4 KiB crypto_acomp test in a one-vCPU KVM guest. In the revised run, median decompression time falls from 3,480 ns to 963 ns. The time reduction is about 72.3%. The original series reported a different run at roughly 71%; the two should not be mixed into one measurement.
This is plausible as a high-impact optimization of overhead: the author identifies CPUID-induced VM exits as particularly expensive in the guest. It is not evidence that the compression format changed or that every archive decompression becomes 72% faster.
Time saved and throughput gained use different denominators
From those reported values, the time reduction is (3480 - 963) / 3480. Under the additional assumption of identical serial operations with no other bottleneck, the reciprocal time implies approximately 3480 / 963 = 3.61 times as many operations per second. That is a derived ratio, not a measured end-to-end application throughput.
For an original application example, suppose the targeted work occupies only 10% of a request's initial duration. Reducing that part to 27.7% of its former time leaves 90% + 2.77% = 92.77% overall: about 7.23% less total time, assuming sequential work and unchanged remaining costs.
Large blocks, native execution, reused contexts and storage-bound workloads may have different overhead proportions. A useful local evaluation would preserve block size, context lifecycle and virtualization settings with the results. Reproducing the actual application path matters more than adopting the largest percentage from the patch email.
Update to v2 proposal using kernel CPU features; retain measured workload and separate latency from throughput.