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

[Yosry Ahmed <yosry@kernel.org>]

On Mon, Feb 23, 2026 at 7:45 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> 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.

Yeah I am not against having a reverse map in general (regardless of
what design we end up having), I just think it has to be justified.
With the current code, the use cases are not that important imo, so we
can potentially drop it.

If new features like migration and compaction require a reverse map,
it can be tied to them, and depending on the use cases, we could even
make the reverse mapping optional depending on whether these features
are enabled or not -- at least in theory.

>
> >
> > 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.

Yeah it's not necessarily related, I was just mentioning that these
are the obvious current users of the reverse map, but I don't think we
should keep the reverse map for them.

>
> 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.

It kinda makes sense in theory, but ultimately it should be whatever
makes the numbers look good for the largest amount of workloads.