On Wed, Feb 5, 2025 at 12:44 AM Yosry Ahmed <yosry.ahmed@xxxxxxxxx> wrote: > > On Tue, Feb 04, 2025 at 07:44:46PM +0800, Kairui Song wrote: > > Hi all, sorry for the late submission. > > > > Following previous work and topics with the SWAP allocator > > [1][2][3][4], this topic would propose a way to redesign and integrate > > multiple swap data into the swap allocator, which should be a > > future-proof design, achieving following benefits: > > - Even lower memory usage than the current design > > - Higher performance (Remove HAS_CACHE pin trampoline) > > - Dynamic allocation and growth support, further reducing idle memory usage > > - Unifying the swapin path for a more maintainable code base (Remove SYNC_IO) > > - More extensible, provide a clean bedrock for implementing things > > like discontinuous swapout, readahead based mTHP swapin and more. > > > > People have been complaining about the SWAP management subsystem [5]. > > Many incremental workarounds and optimizations are added, but causes > > many other problems eg. [6][7][8][9] and making implementing new > > features more difficult. One reason is the current design almost has > > the minimal memory usage (1 byte swap map) with acceptable > > performance, so it's hard to beat with incremental changes. But > > actually as more code and features are added, there are already lots > > of duplicated parts. So I'm proposing this idea to overhaul whole SWAP > > slot management from a different aspect, as the following work on the > > SWAP allocator [2]. > > > > Chris's topic "Swap abstraction" at LSFMM 2024 [1] raised the idea of > > unifying swap data, we worked together to implement the short term > > solution first: The swap allocator was the bottleneck for performance > > and fragmentation issues. The new cluster allocator solved these > > issues, and turned the cluster into a basic swap management unit. > > It also removed slot cache freeing path, and I'll post another series > > soon to remove the slot cache allocation path, so folios will always > > interact with the SWAP allocator directly, preparing for this long > > term goal: Hi Yosry, > I believe this was first raised in some form in LSFMM 2023 [1] :) Oh, Sorry, my bad, I didn't check the history about this well enough... Thanks for the info! > > The approach described here is different, as it's cluster-based, which > is interesting. I am interested to know how this helps separate the swap > core layer from the underlying backing, as Johannes asked. > > In all cases, Nhat is also working on something similar, so we need some > coordination here to avoid duplicated/conflicting work. Right, I saw that, I think this is no fundamental conflict, as so far the cluster based table approach is mostly focusing on the index and allocation/freeing (also swapin/swapout) simplification. Things and ideas mostly emerged while I was working on the swap allocator last year, and to address the discontinuous swapout and min swapout order issue Chris shared some very helpful insights that will come suitable with this approach. I fully agree that we can discuss and figure out a way to arrange the development and implement things with the optimal approach :) > > Thanks! > > [1]https://lwn.net/Articles/932077/ >
