Re: [PATCH 15/16] mm, swap: require zswap for xswap devices

[Baoquan He <baoquan.he@linux.dev>]

On 09/03/26 at 03:52pm, Youngjun Park wrote:
> On Thu, Aug 27, 2026 at 05:45:05PM +0800, Baoquan He wrote:
> > xswap has no backing storage: swapped-out pages live only in zswap.
> > Without zswap, swapout always bounces back, so the device would
> > consume swap entry space without ever freeing memory.  Refuse to
> > create a device when zswap is unavailable.
> > 
> > Runtime disabling of zswap after creation is safe: existing entries
> > stay loadable (zswap_load() gates on zswap_never_enabled(), not the
> > runtime zswap_enabled flag) and new swapouts merely bounce back to
> > memory without freeing it.
> 
> Hello Boaquan.
> 
> If xswap is used alongside another swap device, wouldn't runtime
> disabling of zswap cause a problem? 
> User assumes other remained swap device used right afte zswap disabled.
> 
> Once a device is allocated as xswap and zswap gets runtime disabled,
> xswap keeps receiving new swap entry allocations, and every swapout
> to it just bounces back without freeing memory . until xswap's
> entries are exhausted. Meanwhile the other swap device sits unused.
> 
> If my point is right...
> A few ways to handle this come to mind.
> 
> 1. Once xswap has started accepting writes, refuse to runtime disable zswap.
> 2. If zswap is runtime disabled, stop handing out new entries from
>    xswap (drop it from the available list, or gate on an XSWAP flag).
>    This would also need nr_swap_pages, the visible swap count to be
>    reduced accordingly, and unused cluster memory reclaimed.
>    behave as if xswap had been swapoff'd.
> 3. Support falling back to another swap device once zswap becomes
>    unavailable. 

Agreed. 2) sounds better. Thanks for the detailed analysis.