From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E76E0C02194 for ; Tue, 4 Feb 2025 16:56:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BD566B007B; Tue, 4 Feb 2025 11:56:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36E466B0082; Tue, 4 Feb 2025 11:56:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 234416B0083; Tue, 4 Feb 2025 11:56:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 06BC76B007B for ; Tue, 4 Feb 2025 11:56:56 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A4F244A3E3 for ; Tue, 4 Feb 2025 16:56:56 +0000 (UTC) X-FDA: 83082866832.08.020EE50 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf12.hostedemail.com (Postfix) with ESMTP id A60AC4000C for ; Tue, 4 Feb 2025 16:56:54 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=G0YEwb05; spf=pass (imf12.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738688214; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iYuFVAHt4CPQLeo9KgZMoVBc/SverKMSWFf/qa6W6TM=; b=5SEarxV4QEFON0FNxZrsyYk2+H2mZQmZNVoHJMHBSuqjuqPfEmF4dDkG2uh2MEkMoxfN2T Q3+pLhIfnJIX8p6WaNHib58q7cA8gLLc2/V++Xv8Oy7K2DJkWDxnTnEwK4gDCHrtmIhxrn 3ATeIJjNt//s82CUIzNiCkpdvJhlQX8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=G0YEwb05; spf=pass (imf12.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738688214; a=rsa-sha256; cv=none; b=fwK1DZdo/Z9NReAyBd7Rlfu56ivPeUUEC5ghrZ38ajo050jsyauPNjqy4yTgYTMQYbYABB SRd8biF/e9IyQxq8rF/USG9RZnQ2zpiz+IIhf2eRqoGkIFIPpPG2Bm7puzD0KmqvWTnmxb frvLJTAB25hva28MO2wRi8tVrKA5oTM= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-30229d5b229so58322401fa.0 for ; Tue, 04 Feb 2025 08:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738688213; x=1739293013; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iYuFVAHt4CPQLeo9KgZMoVBc/SverKMSWFf/qa6W6TM=; b=G0YEwb05VqAqSXaDsJELlKfgrR3EwtHoPrxUZ/cE5IRg2aFWxMtsVgAichSoDgbsji +YxBf/16vglSKMWt+SbnzLRRRM6A5L7sCwRqMP2+C7raGYYQ8ByuIZpDhok1NE8GbjQj iBN1uu8i3iBTbWDythHriPUJcUaIWvdE6XOp6Q+6wYpmd+20COxxo0B/2xV7EI9C1f+7 xWfBe2F5C0F7sRxZTqR9oSgScYB+8tJAxmk3rOzZUhUMYPLpDOWvlBMu/PzATWPfBiVH MXY6P0dn5LnoM/ldRz5TlmVS4ua9tY9roofZrF5ITmKVCNgjAk/Stt3EQPaIVFFf5WQH /AIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738688213; x=1739293013; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iYuFVAHt4CPQLeo9KgZMoVBc/SverKMSWFf/qa6W6TM=; b=IKgUi3heU4lrb9Erw2kgbhmqKm2rhZHWEJNktoPsPzKAPc+WeJ2H61ZYwfQNlAe/P/ 6WNgDBwlMcJOZqOzIyfZ/zwn6AbzwKAh7Ia1p/nqEHVhfyJAt9k4WZBM3izTZTiZH/yH g42c3wMlCwIMVyuo1HwZxG2vO8NnAFeV5EefCQwxKIRLL8QKPxMpNqWC3fVnhfIS+6XT AGwvV+pKwiIBWTD7DWj6ZH0x9EmrAFhUJoDctJSmZErTB1Gno+YxAe8ZRpzF73YqV32L UQZSMQvEQsqS82BUGIhUt1QEm/WKtbBSye+O641+18bXhDWb0Fn+UPfc+ljAeiT+JfHw c21Q== X-Forwarded-Encrypted: i=1; AJvYcCV+Lh97d/WF2lOLwmQcMR3mBgIj80pdxxjAVlk0/nmbF6jcXM3wNUaxazHHXBSgqezIMMwCZa/kBg==@kvack.org X-Gm-Message-State: AOJu0YxYnmW2KX2u/bB4bfSiPy+0RD1kzvzTvYDcY4O0najxye916+LN JH5Q49OwxIPRxyP6ctWwjIhPVN/t9cxgrJ/cxx2JOOF83DiKso2fyfFGcwwOON5u+2NzE8QTBY7 cc5/56ahGUmf68Kxo4WwmECovTYCNuwBoOOjh9g== X-Gm-Gg: ASbGncu7Xs6WqPYmSOGU0jdUJi5Ss2dT4aQOpkVNT9Mv45PfiTuSboMGMLqioMWU2hv M22WUUUIzif5yMXX0G2Zhm4FnYcVeZwATSMP8Ujz+x6/B/7/mM02h1rv9lVJBUTZe4vx5E+2a X-Google-Smtp-Source: AGHT+IFBCKGet3AP8hA5RvOLQ3tNkmAM8bo66oVMg0WGv8juy8MIVzpKbTj1UlGrZbyQMmwH1VPGihgKnimlco4Mafw= X-Received: by 2002:a05:651c:1605:b0:2ff:d83d:9155 with SMTP id 38308e7fff4ca-307968c5668mr99502091fa.27.1738688212555; Tue, 04 Feb 2025 08:56:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kairui Song Date: Wed, 5 Feb 2025 00:56:36 +0800 X-Gm-Features: AWEUYZlIGc-mRUyBmbSdySLIecen9XuxBMuYOmuNLR8k22gbBjTLcU4m8ScAJJE Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Integrate Swap Cache, Swap Maps with Swap Allocator To: Yosry Ahmed Cc: lsf-pc@lists.linux-foundation.org, linux-mm , Andrew Morton , Chris Li , Johannes Weiner , Chengming Zhou , Shakeel Butt , Hugh Dickins , Matthew Wilcox , Barry Song <21cnbao@gmail.com>, Nhat Pham , Usama Arif , Ryan Roberts , "Huang, Ying" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A60AC4000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: erub9eymfwfy88hgptbkfw3zb5d68ow1 X-HE-Tag: 1738688214-791200 X-HE-Meta: U2FsdGVkX18aiBHcVihGD0eqHrxSOh8r3NApblaiSbE7tSn+lkwx05gw1qc+usB+hwQNsdZ5E4ktI28Befg+Ml5P2NadEW10YU7mIHYk7bnwCpAZzJs8ITAQMO4l1Wj1eXHa90ORZGik7EJIALKwR2JXExeBv/JRG3Cq4hBKwkQjmNnG3atpVUuS5hTi/EGIFBKlwWs03aJX2wrsx2Wpv4+x+nUZRcgMDRzEI4F3EJVMXFlZkwZtfGDfsvH3lPDLfpBEPIA+jY3+Dg7328ARl9kiRPICcV9VK8qEMSjVsYpmpI08/UhtjsCRodfjO4Sm1Tf0UQE9fgSn9GNqQ5vvbyH7U7UmuN4cwxhXfoJnjkai0KwxHtMNzyUI5HTRRpG5JPnxH9OuLYUJT5PrdIzxlZeBClKBCXtoCJ0G95USYhmZyQXaIDNowaD6HaKZBcQCTeDYjg2dfeoZQ6Sx3ilyZVT0kJsZkVcpmLCzo/Fzj+j/h6NG2ULibg3j4uKm3iVAeizwT/Bm+Ks82vV1c1cX0VMdSXGdBoj1rDrLO0beZp0lB02DSuXTdl9lkcROQ1zrRJLHhthJe0+rZ912TLJ/bqske5e1z458k2XjVG5DuU9CwdNobrIxiPh5oWrHKTWr3fb8m5m+kot4jF5XTjheb9Jvwr4U1b1NKxaiJ45TsMHxQaY1TMnK4FUEBXV5dKdCJ+kI/BKdTrminzxILLAVcJJiftTReUu9yns5MFwVmTmUNwNH+o9Qdj0BoURsdwHCWmSiY8VyB8jGMWkPrweuHopoL250qDRY8ywYIp7seUl0rnVHT8pfJBXMcTHDO1Lbzay/lE+Rxy5adSZ2Ada/KWN6wZ3uI8W9Qbfk/wij9YBRqNGMUDA18sWgnS4E2K2lBkQ1vaHF1BGUf+hcygxBzWBQHTYBqnuMY6tXI3ndqCEZgsrCvO7VVk2pGTVrP/inJf8C1W4TNBiU8lw1PXG 3V9obDBJ klq0d/DWQhCYGjTXi39u2pMbbOQLgsw7YiiGsBdkx2giZ2v49thk1ZdWKBnrqvTxAP1ec5WcGUvCrl3KY9WpNse1hWPpqTf71YK9xyYIo0jpgF/DLjtmoQSzcpDADs5vDGL2GlZXA1J03Sk2WYdiJB+RxewnBeBQAljqFwLqCgc7Qxws2Yqai+XYFqanH/4mCLJn8xykW1inTkXAUufWngvLTCuHy1IAPnVjiuyz3+oKcA8aBICS0dLV7o7RG7IH0KN+15z2Du95e5GxOlHNcRM5qxAlD2zcTlgSIT3Qn1hEuDw90z4Q9xY/UhERgswt7UVLw8WUsE1vKGqxONL8kTUPh9Yqt9+4+y0jE4sX/7Od/ow3tlxNF/5yiAwoe/AJ/gSyf X-Bogosity: Ham, tests=bogofilter, spamicity=0.051740, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 5, 2025 at 12:44=E2=80=AFAM Yosry Ahmed = 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 u= sage > > - Unifying the swapin path for a more maintainable code base (Remove SY= NC_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/ >