Re: [PATCH v5 00/21] Virtual Swap Space

[Gregory Price]

On Thu, Apr 23, 2026 at 01:47:50PM -0700, Yosry Ahmed wrote:
> 
> IOW, I think the whole reason we want a virtual layer is to separate
> the backends, which would facilitate tiering. If the virtual layer is
> itself a swapfile, wouldn't it become one of the tiers?
> 

Sorry to add to the fun, but i do think this is mildly relevant.

I've been testing hardware-compressed RAM as a swap tier (CRAM) w/ vswap.

Will hopefully be publishing soon - but was waiting to see how vswap
would go first.  But I think this is a good insertion point.

With vswap - this integration was so absurdly clean.  We just add
VSWAP_CRAM and being able to writeback the folio to zswap or regular
swap was surprisingly straightforward.

The alternative was to inherit an absurd amount of boilerplate from
zswap, and then the complexity explodes if you have to decide whether to
go to backend X or backend Y.

So I just wanted to say, in support of this series, there is functional
value in the virtualization here that isn't fully represented by just
zswap/zram/swap interactions.

> I think this was discussed before but I still wonder if we really need
> a reverse mapping, if it's only to optimize swapoff then I don't think
> it's a requirement. We can still scan the virtual swap layer to look
> for slots to swapin. It would still be better than scanning the page
> tables as we do today. But I think there were other use cases for the
> reverse mapping, I just forgot what they were.

For the sake of discussion - there may be value in the reverse map for
CRAM, since it can soft-fault its folios into page tables read-only.  In
this case, you can have multiple mappers in various states (softleaf vs
read-only).

In the case that you want to writeback a multi-state cram folio, the
reverse mapping may be useful.  Right now I'm using rmap, but maybe
there's an optimization here.

Maybe not worth it "until something actually uses it" though.

~Gregory