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 B9679C02198 for ; Tue, 4 Feb 2025 19:09:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D0AF6B008A; Tue, 4 Feb 2025 14:09:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 359D16B008C; Tue, 4 Feb 2025 14:09:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D4126B0092; Tue, 4 Feb 2025 14:09:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EEDDA6B008A for ; Tue, 4 Feb 2025 14:09:12 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A2191A0CBE for ; Tue, 4 Feb 2025 19:09:12 +0000 (UTC) X-FDA: 83083200144.11.3070ED1 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf03.hostedemail.com (Postfix) with ESMTP id 6179820003 for ; Tue, 4 Feb 2025 19:09:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=Hvn0pVC5; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.178 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738696150; a=rsa-sha256; cv=none; b=XPz+QnWkBvXdZptsuuanNR4aF01qJNplRJg5ayzLI+hg8Mm3/Id7bxVAPgQA9+k1GSEu/E SLRbEQYSvSQ9zcfz5YSxGbbBQo2a3zML0n2//h3Ete+L1verkAd/HAr+y/vac+Fd/LMxlM pReEf1J73sKbPKw82kJR0nCH+FMi/oA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=Hvn0pVC5; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.178 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738696150; 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=3DzA8EuKZCrU1KctGnNFxV6mkXVRNx73P0O/Qz0AKVY=; b=I433mz+pl6wdo1uT43LAQyKu182IkyVtfvXT/2HzIytn0UZdzX+tG0HaSCKprukT12Koj9 n2YYoXdMRYv1h+4b7YIuXmcgN3Dh+JIjnQA+E86H/GwMFBq8zI5wuDWwjNUW9MsH1eOSS7 yX/b6yRQWY/sGgcQlfnTSVvcXgUK6jc= Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-7b6e8814842so607844285a.0 for ; Tue, 04 Feb 2025 11:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1738696149; x=1739300949; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=3DzA8EuKZCrU1KctGnNFxV6mkXVRNx73P0O/Qz0AKVY=; b=Hvn0pVC5LD7DSsfTRxhqu1jbAN59/p+5pQfKu0un8WQRCVdhxnss3G1Raxd12f+3Pz LcL0vGkGumHD0IUf5AYJyxrrHjmqGQ3gaeRbc35CPwRN8hmwUs2XN9EETO9Wc/zO7dfo Fp/ggo2FuWDNVWPpIf02j4D9qJ5YdJBy+IuytenNuCfzjtvFtsUmWIhNIhCzTgYeLlVw 9UdStMyBSrO2ISVyD82i3uHOQ9h6RlWhYVHw0yikAmJSINx+EmRvJD631kv/A9mSmvHG a3u+BQ+7FzZetPra1tQaQNSga4voeYOGRIey0lDsdJuq2yfL9HB5Md6ZeR7PgVbDbIOh Vs0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738696149; x=1739300949; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3DzA8EuKZCrU1KctGnNFxV6mkXVRNx73P0O/Qz0AKVY=; b=jesnrkEq1h5wRhWQ6JXx1MHOV+56zMeoXM483E58qpS+ZU7zjek9rCb3Dz1Q729lwD KphJ42tQvptruGA/VmWQUAQL/TgiwJMLBBkufPSutiCgte2R/whBt95ZWne6pF5TWlzX vkVBTMZ/cColpeyc4akorgJBB0uUwj/XYv4jtCTtkvkhTZXXfmv9my9fR+79OICvz1XS kg5nfIm5aYe2rDPVWkXVNa+k2AK/h9pjM1lkxsUzg7rNDfr4xmKudovaYtUQZsu2u+2X UfE+a0hI4gyt7EtOEYUzrPIAdyLUbmY0uMlLYQmTJmS8eEVLCb8s2RRY4CUeRQpFP0Gf 4rHQ== X-Forwarded-Encrypted: i=1; AJvYcCX3m/M2vGJn73wmD9FKgo1YjC03yChnOzMCYptbU4oIhoyIje4z0aeJ7s2JSV2ak81NwaK9hqY5qA==@kvack.org X-Gm-Message-State: AOJu0YzLO+/vM0cVCzAkETWlKaGFjlPIHDwQC37w5q7j9XZaOB2PoTMm U/XbsxXC3VDHuMitDK29Sq+puA4redTu2XrZkDffwA6P58fcV7E0uJLpT1HewCQ= X-Gm-Gg: ASbGncs8AXn/hbNvEDKpo+UDsWIlhgOd3yR8fM0Dz3rcQ0EunUPcscvHFmOGYheb2PW 2PxnBzE93MvlmqaXgbmscTOz1QW6jWDbROF4wp7URnyiEN0FWP69T3W1ccTZkPsF61cDmtiMMyd fWXds5umRSQii/n7FIqMJYZ9tDvBI/xm8OcoaGp7S3dyDMgQmdwXIgdqa3dVw3jV5p5gW7EUFdz iYzAZoT8tkI1h9dHK41KalADXi2hYZlVugpKn81wnSeig6YDo2ZV7YNRPqKHKvnVWp78WfwlnBs gS0tQQrWHdXUdw== X-Google-Smtp-Source: AGHT+IH1/PPzjdIJivsx1G4YTbH4HmMl/sS0Vp/o7SmecmovXFqSenlif4iAPgBvMlawYCtQs+HapA== X-Received: by 2002:a05:620a:bc3:b0:7b6:d089:2757 with SMTP id af79cd13be357-7bffcd735e1mr4031503285a.35.1738696149352; Tue, 04 Feb 2025 11:09:09 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with UTF8SMTPSA id af79cd13be357-7c00a8d0273sm664619085a.44.2025.02.04.11.09.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2025 11:09:08 -0800 (PST) Date: Tue, 4 Feb 2025 14:09:04 -0500 From: Johannes Weiner To: Kairui Song Cc: Yosry Ahmed , lsf-pc@lists.linux-foundation.org, linux-mm , Andrew Morton , Chris Li , Chengming Zhou , Shakeel Butt , Hugh Dickins , Matthew Wilcox , Barry Song <21cnbao@gmail.com>, Nhat Pham , Usama Arif , Ryan Roberts , "Huang, Ying" Subject: Re: [LSF/MM/BPF TOPIC] Integrate Swap Cache, Swap Maps with Swap Allocator Message-ID: <20250204190904.GC705532@cmpxchg.org> References: <20250204162426.GB705532@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6179820003 X-Stat-Signature: 7txkxyqywcemdqtehqtio9j7t67fdfnr X-HE-Tag: 1738696150-899293 X-HE-Meta: U2FsdGVkX19yiN/avPx9MoEhUsKK8C15Aibv/CbGVbzfIQCyfGsG5xFO9CGrbwXqvXR98EXcNCKm3KHH/yVuXu3jxQuBn2bUfzYtN8S/81HYoGOqi5/yDpQqDcuhRWPvPwow/huCIVe7beRmta4Q/Oa120N0C86+GF2AJgf2S+roT5DKyHxxR1RKLLv6x4TZSQWr3P9iHZmRJhK4gaRGLb0JReXNsLk9UFplbvPmfWYmVv7yvs5Xys6MVR087v7F8yTGsuDjWU0EinWZAU40ne/bY/D0rdMAfvCcZWdSQ7zFFV9hy3aAtZL5VU0uVEJpnZoR4CPA2GE3wQ56TVP0UsmWHm2rsJUyTCIob1oMFRkEuxpjqqxiah0kMW9qC3tZDb0DpV80SJOCsB4P8KQ63SrVVB2qvIdqtufZrDrXkX80X9Ajc7saH1DIjgtlxizzVDNqz4ZIGdHtXyxvCAyalu5UIcBh61fyKF227woBPebaxPJwZTDUlwp7jcB76H5apqsXbmpG/AXG5/RXakB6xBb5e7071x0OqLjk0NukyBTLHCkD53wSxFT6koaVP8lbk2DRqTeXNPU/7paLV63B005Uo7h4IU1ex4st3iRGub90t7Tl8BnithjMJDZSv+fDEBT2wJtLKdy1j5zMahpHWqlF5Y5OG0okByMuZ78tGzpswj0+JpRiurqvr4Zap4jYPFzMMDObFAZMMm6MMmSSorIoMyc0aPstcxL9Y74aGdjSJcNrLxFCmNZZ7jVfebXf/PjmHJoZ0z6rdKJPgRt5MdD6wDVRs0W0v+Ekqh+jX9647T7117V9wUM9d3MM4a9DaGHH/PMc9fRW2ZzwPwaNGbCIt+Ji+RU/tOXWLGpCsAO5Ny1XMiARvV6nrOF9GXqWzgqzhFc0R+l9VAXisa3K9d0iAz3Lp6NmdOWgXfNqcE2BwlTktIw63a5eYgEn/ZONUdhujGOW896yQOBf4V9 TF0FbXR6 XDBOzYkZFnomqGoe8owvQ7XfCquvNkbN1S7HJOksBIJTuCYiGetFimnPDvFr6SIQU2HZEo/Z9HYgDL/53lu5CFzK0WlsXl+WiEyHp679JDDUxJXT2lg+qLUuyszAk1myHof6DMecVfCew/zFQ0oTZvzpXsmjuPfLl5/b8gnRk/+u5u0JGmiQdoYfm+EaAcAl9ulKg3Bbpr8wuyKj6B6DAy/uWhvzwYuov0hCaD7BC0IdrE2D8ICGrDWf/Gn1R5z1JRPNYWh/d8ccpQV1Qm1yj5YqYll1h/t72OyjWLCX77RVVghdF60xDY3N4BZ7dHAdN1mAt8zQSAT3fc2kfa65HdTb5kLddis2sCHCvs+5hIT9Xn7Q9LXgj1mS+yRPbreIlQOMKQQQv76DJZN5ykYk0z+vGJUgeK1XHNC6QHRasU0Ed7/T8cJZEG12vYIWZ3yzK30tYQnEHeHHSbCU31nZI3yWoO29vJQGvjfZ5euHc/vC8yTUBXO+DF63XpIVrt4Hgoj1sOhWffZsWJeG01Mfx5DDi/G2Lw/CVo+B9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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 05, 2025 at 02:38:39AM +0800, Kairui Song wrote: > On Wed, Feb 5, 2025 at 2:11 AM Yosry Ahmed wrote: > > However, what we should *not* do is have these clusters be tied to the > > disk swap space with the ability to redirect some entries to use > > someting like zswap. This does not fix the problem Johannes is > > describing. > > Yes, a virtual swap file can have its own swap space, which is indexed > by the cache / table, and reuse all the logic. As long as we don't > dramatically change the kernel swapout path, adding a folio to > swapcache seems a very reasonable way to avoid redundant IO, and > synchronize it upon swapin/swapout, and reusing a lot of > infrastructure, even if that's a virtual file. For example a current > busy loop issue can be just fixed by leveraging the folio lock: > https://lore.kernel.org/lkml/CAMgjq7D5qoFEK9Omvd5_Zqs6M+TEoG03+2i_mhuP5CQPSOPrmQ@mail.gmail.com/ > > The virtual file/space can be decoupled from the lower device. But the > virtual file/space's table entry can point to an underlying physical > SWAP device or some meta struct. It's a bit unclear to me still which level will use the struct swap_cluster_info in the layered scenario. Would it be the virtual address space, where ->table has tagged pointers to resolve to swapcache/zeromap/zswap/swapfile? Or would it be the swapfile space, where ->table resolves to disk slots? Or are you proposing to use the same struct on both levels, with ->table catering to different needs? Keep in mind, in the virtualized case, it's the top layer that would have to keep track of the page table count, the swapcache pointer and likely the memcg linkage. That also means the physical layer could likely be reduced to a single bit per entry - used or free. I suppose void *table could also point to such a bitmap? But not sure about the other members that would become redundant/unused.