On 2024/3/5 06:58, Matthew Wilcox wrote: > 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. Right, I also thought about this direction for some time. Apart from fewer IO, there are more advantages we can see: 1. Don't need to allocate a page when write out compressed data. This method actually has its own problem[1], by allocating a new page and put on LRU list, wait for writeback and reclaim. If we write out compressed data directly, so don't need to allocated page, these problems can be avoided. 2. Don't need to decompress when write out compressed data. [1] https://lore.kernel.org/all/20240209115950.3885183-1-chengming.zhou@xxxxxxxxx/ > > I'm sure it'd be a big redesign, but that seems to be what we're talking > about anyway. > Yes, we need to do modifications in some parts: 1. zsmalloc: compressed objects can be migrated anytime, we need to support pinning. 2. swapout: need to support non-folio write out. 3. zswap: zswap need to handle synchronization between compressed write out and swapin, since they share the same swap entry. I must missed something, more discussions are welcome if others have interests too. Thanks!
