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

[Yosry Ahmed <yosryahmed@google.com>]

On Tue, Mar 28, 2023 at 2:22 PM Chris Li <chrisl@kernel.org> wrote:
>
> On Tue, Mar 28, 2023 at 12:59:55PM -0700, Yosry Ahmed wrote:
> > > So it wouldn't be my first preference. But it sounds workable.
> >
> > If we settle on this as a first step, perhaps to avoid any ABI changes
>
> Turn on zswap without a real swapfile is user space visible change.
> Some small change is unavoidable, ABI or not.

Yes, but to support the ghost swapfile use case we have to make swapon
support files with holes and/or 0-block length -- which is a bigger
change user-visible change and also includes a change to the swapon
utility.

>
> > we can have the kernel create a virtual swap device for zswap if it is
> > enabled, without userspace interfering or having to do swapon on a
> > sparse swapfile like we do today with ghost swapfiles at Google. We
> > can then implement indirection logic that only supports moving pages
> > between swap devices -- and perhaps only restrict it to only support
> > the virtual zswap swap device as a top tier initially.
>
> One more things to consider is that, Google use more than one ghost
> swapfiles for zswap due to scalability. There might be scalability
> implication if there can be only one zswap device.

Yes, but I believe this can be (and should be) handled within the
kernel. We can find the sources of scalability problems with a single
swapfile and mitigate them. I suspect the tree lock in zswap is one of
them. The swap cache lock might be another one, but the swap cache is
already partitioned within each swapfile to address that.

>
> Chris
>
>