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

[Yosry Ahmed <yosryahmed@google.com>]

On Thu, Mar 23, 2023 at 12:50 PM Chris Li <chrisl@kernel.org> wrote:
>
> On Thu, Mar 23, 2023 at 11:40:35AM -0700, Yosry Ahmed wrote:
> > > Thanks for the clarification. If we have swap_desc index in the PTE,
> > > let's call it S1. I assume S1 will contain A1 and B1 as part of the
> > > swap_desc struct.
> > >
> > > Now we are getting to some very interesting details.
> > >
> > > What is the life cycle of the S1? Does S1 share the same index as A1?
> >
> > The idea that we are currently discussing does not involve a swap_desc
> > struct. There is only a swap ID that indexes into an xarray that
> > points to a swap_entry. This swap ID and the xarray formulate the
> > indirection layer.
>
> I see. The swap_entry is the same size as the swp_entry_t, which is
> unsigned long.
>
> > I am guessing in this design the swap ID is allocated when unmapping a
> > page to be swapped out, and freed when the underlying swap_entry's
> > swap count falls to 0.
>
> If none of the swap pages on A need to move to B (yet). Does it still
> need to allocate an entry in the swap ID xarray, only pointing to A1?
>
> At the time of swap out page into A, we will not know if it will
> move to B in a later time. I guess the swap ID xarray look up always
> needs to be there?

If the indirection is enabled, yes.

>
> > Moving a page from a swap backend A to another swap backend B should
> > not be a problem in terms of the swap cache, as we will add it to the
> > swap cache of B, modify the swap ID mapping to point to B, then remove
> > it from the swap cache of A.
>
> That means when B swap in a page, it will always look up the swap ID
> xarray first, then resolve to the actual swap_entry B1.

Yes. There is an extra lookup.

>
> > There are some concerns with this design that I outlined in one of my
> > previous emails, such as having separate swap counting implementation
> > in different swap backends, which is a maintenance burden and
> > error-prone.
>
> I agree that allocating the swap ID and maintaining the free swap ID
> would be some extra complexity if we are not reusing the existing swap
> count code path.
>
> My other concern would be the swap ID xarray indirection is always there
> regardless if you need to use the indirection or not.

I think the idea is that this design is more minimal than the proposed
swap_desc, so we can have it behind a config option and remove the
indirection layer if it is not configured.
However, I am not yet sure if this would be straightforward. I need to
give this more thought.

>
> Chris