Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap

[Chris Li <chrisl@kernel.org>]

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.

Chris