[..] > > I think we shouldn't put these poorly compressed output into zswap, > maybe it's better to early return in these cases when compress ratio > < threshold ratio, which can be tune by the user? We have something similar at Google, but because we use zswap without a backing swapfile, we make those pages unevictable. For the upstream code, the pages will go to a backing swapfile, which arguably violates the LRU ordering, but may be the correct thing to do. There was a recent upstream attempt to solidify storing those incompressible pages in zswap in their uncompressed form to retain the LRU ordering. If you want, feel free to start a discussion about this separately, it's out of context for this patch series. Thanks!
