Re: [PATCH v5 00/12] mm, swap: swap table phase IV: unify allocation and reduce static metadata

[Kairui Song]

On Sun, May 17, 2026 at 11:40 PM Kairui Song via B4 Relay
<devnull+kasong.tencent.com@xxxxxxxxxx> wrote:
>
> From: Kairui Song <kasong@xxxxxxxxxxx>
>
> This series unifies the allocation and charging of anon and shmem swap
> in folios, provides better synchronization, consolidates the metadata
> management, hence dropping the static array and map, and improves the
> performance. The static metadata overhead is now close to zero, and
> workload performance is slightly improved.
>

Sashiko only gave a warning this time (and it's false positive):

> For devices using the swap cache, __swap_cache_add_check() enforces
> uniform zero flags. If the flags are mixed, it rejects the insertion with
> -EBUSY. Could the readahead and swapin fault paths then treat this as a
> transient race and unconditionally retry in an infinite loop, causing a
> kernel livelock?
> For devices that support synchronous IO and bypass the swap cache,
> swap_read_folio_zeromap() detects the mixed status, triggers a warning,
> and returns true without marking the folio uptodate. Would this cause
> do_swap_page() to abort with a SIGBUS?
> Should can_swapin_thp() retain a check to verify the uniformity of the
> zeromap status across the batch before allowing the swapin?

And no we don't need that, __swap_cache_add_check already unifed the
check. There is no device bypassing swap cache now.
swap_cache_alloc_folio now handles the fallback or returns the proper
error code.