From: Christoph Hellwig <hch@infradead.org>
To: Chris Li <chrisl@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
YoungJun Park <youngjun.park@lge.com>,
lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM/BPF TOPIC] Flash Friendly Swap
Date: Mon, 23 Feb 2026 05:23:00 -0800 [thread overview]
Message-ID: <aZxUtFaVaJbkAM8Z@infradead.org> (raw)
In-Reply-To: <CACePvbW6uT5OKDg0RWS3ZBGcppBkz+MREDVXdwSat_qM=Nc5CA@mail.gmail.com>
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.
>
> > 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/
And it should just be the default block device (and maybe file backed)
swap.
next prev parent reply other threads:[~2026-02-23 13:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 12:46 YoungJun Park
2026-02-20 16:22 ` Christoph Hellwig
2026-02-20 23:47 ` Chris Li
2026-02-23 13:23 ` Christoph Hellwig [this message]
2026-02-23 18:15 ` Chris Li
2026-02-23 18:53 ` Pedro Falcato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZxUtFaVaJbkAM8Z@infradead.org \
--to=hch@infradead.org \
--cc=chrisl@kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=youngjun.park@lge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox