Messages in this thread |  | | Date | Wed, 3 Jun 2026 19:00:23 +0000 | | From | Yosry Ahmed <> | | Subject | Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition) |
| |
> > > I don't like that the code bifurcates for vswap vs. normal swap entries > > > though. Not sure if this is an issue that can be fixed with proper > > > abstractions to hide it, or if the design needs modifications. I was > > > honestly really hoping we don't end up with this. I was hoping that the > > > physical swap device no longer uses a full swap table and all, and > > > everything goes through vswap. > > > > > > I hoping that if redirection isn't needed (e.g. zswap is disabled), > > > vswap can directly encode the physical swap slot so that the reverse > > > mapping isn't needed -- so we avoid the overhead without keeping the > > > physical swap device using a fully-fledged swap table. > > > > Can you expand on "vswap can directly encode the physical swap slot"? > > I'm not sure I follow here. > > > > > > > > All that being said, perhaps I am too out of touch with the code to > > > realize it's simply not possible. > > > > > > Honestly, if the main reason we can't have a single swap table for vswap > > > is saving 8 bytes on the reverse mapping, it sounds like a weak-ish > > > argument, even if we can't optimize the reverse mapping away. But maybe > > > I am also out of touch with RAM prices :) > > > > In terms of the space overhead I do agree, FWIW :) > > > > I think the other concern is the indirection overhead with going > > through the xarray for every swap operation, hence the per-CPU vswap > > cluster lookup caching idea: > > > > https://lore.kernel.org/all/20260505153854.1612033-23-nphamcs@gmail.com/ > > > > > > > > I at least hope that, the current design is not painting us into a > > > corner (e.g. through userspace interfaces), and we can still achieve a > > > vswap-for-all implementation in the future (maybe that's what you have > > > in mind already?). > > > > That's still my plan. Operationally speaking, I want to make this > > completely transparent to users, with minimal to no performance > > overhead. > > I do want to add that, even without achieving this, the current design > already enables a lot of use cases. I think it is a good compromise to > maintain both virtual and directly mapped physical swap entries for > now, and revisit the conversation of whether we can afford a mandatory > vswap layer once all the optimizations have been done :) > > We should strive to simplify the codebase, and it will naturally > happen when the original overhead concern is no longer there. A > swap-related example: a few years ago, everyone thought swap slot > cache was needed. But then, Kairui optimized the swap allocator's lock > contention issue away, and that swap slot cache is suddenly redundant. > That finally allowed us to get rid of it. Similar thing happened (or > is happening?) with the SWP_SYNCHRONOUS_IO swapcache-skipping > heuristics.
I agree, I just want to make sure we have a line of sight (or at least no blockers) to having a unified vswap layer in the future.
|  |