Re: [LSF/MM/BPF TOPIC] Flash Friendly Swap

[Chris Li <chrisl@kernel.org>]

Hi Christoph,

On Fri, Feb 20, 2026 at 8:22 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> Honestly, I think always writing sequentially when swapping and
> reclaiming in lumps (I'd call them "zones" :)) is probably the best
> idea.  Even for the these days unlikely case of swapping to HDD it

For the flash device with FTL, the location of the data written is
most likely logical anyway.  The flash devices tend to group the new
data internally to the same erase block together even when they are
discontinuous from the block device point of view. It is easy to write
out sequentially when the swap device is mostly empty. That is how the
cluster allocator does currently any way. However, the tricky part is
what when some random 4K blocks get swapped in, that will create holes
on both the swap device and internal write out data. Very quickly the
free cluster on swap devices will get all used up and that you will
not be able to write out sequentially any more. The FTL layer
internally wants to GC those holes to create a large empty erase
block. I do see where to pick up the next write location can have a
huge impact on the flash internal GC behavior and write amplification
factor.

> would do the right thing.  So please no conditional version that need

I agree. There is another LSF/MM topic related to this, the plug-able
swap ops backends. I hope that the flash friendly swap layout can
implement the swap ops framework without conditional versioning nor
stack block drivers.

https://lore.kernel.org/linux-mm/aZiFvzlBJiYBUDre@MiWiFi-R3L-srv/

BTW, I am very interested in this topic and want to participate in the
discussion.

> opt-in or stacked block drivers, let's just fix swapping to not be
> stupid.

With the cluster allocator and the recent swap table change, the swap
is a lot better than it was before now. Anyway, feedback to the core
swap stack is always welcome.

Chris