On Fri, Mar 01, 2024 at 04:53:43PM +0700, Nhat Pham wrote: > IMHO, one thing this new abstraction should support is seamless > transfer/migration of pages from one backend to another (perhaps from > high to low priority backends, i.e writeback). > > I think this will require some careful redesigns. The closest thing we > have right now is zswap -> backing swapfile. But it is currently > handled in a rather peculiar manner - the underlying swap slot has > already been reserved for the zswap entry. But there's a couple of > problems with this: > > a) This is wasteful. We're essentially having the same piece of data > occupying spaces in two levels in the hierarchies. > b) How do we generalize to a multi-tier hierarchy? > c) This is a bit too backend-specific. It'd be nice if we can make > this as backend-agnostic as possible (if possible). > > Motivation: I'm currently working/thinking about decoupling zswap and > swap, and this is one of the more challenging aspects (as I can't seem > to find a precedent in the swap world for inter-swap backends pages > migration), and especially with respect to concurrent loads (and > swapcache interactions). Have you considered (and already rejected?) the opposite approach -- coupling zswap and swap more tightly? That is, we always write out the original pages today. Why don't we write out the compressed pages instead? For the same amount of I/O, we'd free up more memory! That sounds like a win to me. I'm sure it'd be a big redesign, but that seems to be what we're talking about anyway.
