Re: [LSF/MM/BPF TOPIC] Swap status and roadmap discussion

[Kairui Song <ryncsn@gmail.com>]

On Tue, Feb 24, 2026 at 2:55 AM Yosry Ahmed <yosry@kernel.org> wrote:
>
> > > - Is 64 bits really needed for reverse mapping? For the context, reverse
> > >   mapping here is a swap entry recorded in a lower / physical device
> > >   pointing to the ghost / virtual device.
> >
> > I think you can compact this a bit. Swap space itself is not fully 64
> > bits right?
> >
> > Just not sure if the juice is worth the squeeze to save a couple of
> > bits here and there, especially if the reverse mapping is already
> > dynamic :)
>

Hi, thanks for the comment.

> I think we should actually revisit the need for a reverse mapping to
> begin with. For swapoff, we can probably scan the virtual swap space
> looking for entries that belong to the backend being swapped off. Not
> as efficient as a reverse map, but still better than the status quo of
> scanning page tables. I don't think optimizing for swapoff is worth
> the consistent overhead.

Right, I don't really think swapoff is worth that much effort too. But
there are still ideas like migration and compaction, which could
really make use of a proper reverse map.

>
> The other use cases are probably cluster readahead and swapcache-only
> reclaim, and I think both of these can also be revisited.

Agree, readahead and swap cache reclaim do need some revisit... Not
related to the revert map idea though.

I'm thinking if we can make the swap cache completely lazy and never
reclaim it proactively for non-RAM swap. And for RAM based swap
(zswap / ZRAM), do the opposite, always ensure swap cache is
reclaimed after use.