Re: [PATCH] lib/lz4: add software-pipelined prefetch to decode fast loop

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 13 Oct 2026 03:20:10 +0000 Biplab Raut <Biplab.Raut@amd.com> wrote:

> From: "S. Biplab Raut" <Biplab.Raut@amd.com>
> 
> LZ4 decompression of cold 4 KiB pages (the zswap/zram hot path) stalls
> on cache misses because the input stream (compressed) and output buffer
> (uncompressed page) are not resident in L1/L2. Insert read-ahead and
> write-intent prefetch hints at the top of the decode loop in
> LZ4_decompress_generic() to overlap memory latency with decode work.
> 
> The prefetch distances (96 B read, 128 B write) are tuned for the
> page-at-a-time workload where both buffers fit in L1d. Prefetch is
> architecturally a no-op hint on all Linux-supported architectures;
> it never faults, never changes correctness, and compiles to nothing
> on targets without hardware prefetch.
> 
> Measured on AMD EPYC 9755 (Turin, 2S×128C), Ubuntu 24.04, kernel
> 6.8.0-90-generic, real zswap path (cgroup-constrained MADV_PAGEOUT +
> full scan-back), Silesia corpus, 15 paired rounds:
> 
>   Kernel LZ4 median scan:  1.0994 s
>   Patched  median scan:    1.0472 s
>   Median paired speedup:   5.09%  (range 4.19%–6.99%)
>   Patched was faster in all 15 rounds.

Well that's nice.  I can't actually recall a case where prefetch made a
measurable difference, although I'm sure there are such cases.

We used to use prefetches often (10+ years ago) but it seems to fallen
out of favor.  This code is a prime candidate.  mm/ barely uses
prefetch.  Maybe it should,