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? > 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. > 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. Chris
