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

[YoungJun Park <youngjun.park@lge.com>]

On Mon, Feb 23, 2026 at 05:23:00AM -0800, Christoph Hellwig wrote:
> On Fri, Feb 20, 2026 at 03:47:18PM -0800, Chris Li wrote:
> > 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.
> 
> Yes, but that's not the point..
> 
> > 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.
> 
> And that is the point.  The FTL will always do a bad job with these work
> loads.  You should not do overwrites, and can do much better
> optimizations in the MM based on that.  I'm pretty sure YoungJun can
> explain all what they did.

+CC taejoon.song@lge.com

Yes, relying solely on Random I/O handled by the FTL does not optimize for
the device's lifespan.

Sequential writes at the OS layer are what create the optimization for
lifespan.

However, if lifespan is indeed a critical factor, deduplication is needed
to reduce the write amount itself. This is another key aspect of the
proposal.

Regarding Chris's mention that overwrites are inevitable, I will address
that part in a separate reply to Chris's email.

Best regards
Youngjun Park