On Thu, Mar 02, 2023 at 09:47:06AM -0800, Chris Li wrote: > On Wed, Mar 01, 2023 at 04:58:08PM -0800, Yosry Ahmed wrote: > > > The indirection layer would be essential to support it but it would > > > be also great if we don't waste any memory for the user who don't > > > want the feature. > > > > I can't currently think of a way to eliminate overhead for people only > > using swapfiles, as a lot of the core implementation changes, unless > > we want to maintain considerably more code with a lot of repeated > > functionality implemented differently. Perhaps this will change as I > > implement this, maybe things are better (or worse) than what I think > > they are, I am actively working on a proof-of-concept right now. Maybe > > a discussion in LSF/MM/BPF will help come up with optimizations as > > well :) > > How about we just put the indirection layer into the swap device? > > For the zswap, it registered its own swap device type, as many as needed. > The indirection is that, it is up to the swap device type to interpret > the offset and swap counts. Maybe it even has its own address space > and address space ops. > > The zswap does not have swap_map and has its own xtree to look up > the zswap entry. > > The common swap device related operation can have some swap related > swap_device_ops function call back. e.g. get swap_cout. > That way, obviously there will not be much memory overhead for > the devicethat doesn't use zswap. > > The zswap entry can still do something similar to your swap_desc, save > some pointer to its nested backing device(normal swap file). > That way the swap_desc overhead is purely on the zswap side. The problem with that is that zswap needs to be able to write its cold entries to flash. If zswap and the backing file don't live in a shared swap id space, it means that zswap writeback would have to allocate a new device/offset tuple and update all the page table references. It would impose the complexity of swapoff on every zswap writeout.
