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 B72B2C2D0CD for ; Wed, 21 May 2025 18:36:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32F136B0089; Wed, 21 May 2025 14:36:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 305B76B008C; Wed, 21 May 2025 14:36:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F5056B0093; Wed, 21 May 2025 14:36:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 012AC6B0089 for ; Wed, 21 May 2025 14:36:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4D606141047 for ; Wed, 21 May 2025 18:36:23 +0000 (UTC) X-FDA: 83467770246.30.8B756A3 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf04.hostedemail.com (Postfix) with ESMTP id 7BFC840006 for ; Wed, 21 May 2025 18:36:21 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a8mWH3Nf; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@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=1747852581; 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=d3SVSn80A89VtHlOJJwihePJqkplewKhlFr2+GPhkBM=; b=JUjl+jNzdgdkzNUGsDeyU8DQARgLLpfl+/aMaosSlqm5B/TN0zq1GyRFlGOQHdWgTxb7zf uw4I/RNgAYo4DrdOLI4gV1txzOnUu+iDk371n0WfqVIy+/v+ClY6Whj44h5hFvmtnynPEg 6K/B8Mapu64fuAJ/vwdaptI5f+UxsOc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a8mWH3Nf; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747852581; a=rsa-sha256; cv=none; b=FYZwPUK0e5zvd+kBkYFEAfJSfMZCdNLuu1p3Z18pVh2FygxWlYI/+XE3pnDUKao+qdp5gQ zP7mqsGQqesnith+1MhqaBgoNFxSdQlbMst8fgd+m1dnU6J9nQRgNMvUvd169UUptihSQ3 EPfxX4X/lsLiaSkFHlLJVeWiPKMXDDY= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6f8cb6b3340so69101816d6.1 for ; Wed, 21 May 2025 11:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747852580; x=1748457380; 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=d3SVSn80A89VtHlOJJwihePJqkplewKhlFr2+GPhkBM=; b=a8mWH3NfDPmH1/MUCNUeuqOLUHOfEaagI9ZntseEV+RXSnPsLc7QWw4ySapwytYqJ/ rHA8+eO+aPhd+ZEdW4Jqicl5+kBHegSKdbwxfYSH+bL569PA4juLXVnMNiBcpsNGy+Pn eSMNDFgdrMvpBjL6zlDfPaXh/MfS1HKwtsxfEXpK0TblaEJKbiojv+kY4eifUEbc7kSi xQFCV5q+McZdkpXLDuiknOyFFhBZB/bj/sldFGdsS56TwyGW0Kwb5LObvJ+jnWrZqmPz GY9YMCU18AykYuoKZd6Ns/vr26Gdhf37xtZz41TD2aaKKhg1xWvkz9OdfZICaKLIAJHF 0IKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747852580; x=1748457380; 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=d3SVSn80A89VtHlOJJwihePJqkplewKhlFr2+GPhkBM=; b=a2qhnCQJscugWwTgwo+aWKREv85E/ytHzi/Jv7d5HHthnZ7fFWoFI1yt2hAfnAqDWu zoQ4/cY2aX0K7ZiGm1zurvq53a3lnQhEmWnbdupySlfQaGv7tIHpKY3sSREb3/QLcPYp dBUN+EqEvWVY+ymHrpiYLNR7ah2+xFWOdI6QYwyDS/rgnzFXjC7nE2fUvgXIL4Qi8ksJ fqF93PZBiIKRtthzBUXhWpLKg4vERY1KR4N0TU/rEhTupT3iLiumtZ9UMrr7hXT970mv XAit8LST44OHD+/AoAPUbVZUzMBDFE2gA8HUfzf0/cgzUcO5VEusvvgc/cIkENOZd0kg cmFQ== X-Gm-Message-State: AOJu0YwdG2EWo8wIo8gb8GtxTwmu84HPa52hM4J+Z9EQnDtCjecEltUP QLeEQANIK6DGWYFYRMByUGKjqYhx5IZ8sPUvnsGQC+zpHw4jiDkZEvuVp40Gx1eXgispKooA1YC 5jiv78q3jKktXFRHvJWh6+Y/qMVuJEnk= X-Gm-Gg: ASbGncvy6bepLXicrM85NA9jW24boVZIscjQ3nJ4gdgv7FtUb23vpCt/8KDiflRYgz+ DhVqxDM0RbLDbeh2az7qnW7DBSjwWRhQy5WmQy1GBi48h/vHEXj/G/acIeFc/w5HIjqlCgg1YI6 HVozjHCaN/deFwNDV2c7TD0Xz+cjpJW037bQ== X-Google-Smtp-Source: AGHT+IE8Iza4954QdCbMrwJijNWRK7AMVEUlTp1V/uCTwoWWz3UsGzoDHW7UKvwUVQpAfgciyAvqnSfWKp3QDZrnxaA= X-Received: by 2002:a05:6214:226e:b0:6d4:dae:6250 with SMTP id 6a1803df08f44-6f8b2d15075mr394285706d6.34.1747852580529; Wed, 21 May 2025 11:36:20 -0700 (PDT) MIME-Version: 1.0 References: <20250514201729.48420-1-ryncsn@gmail.com> <20250514201729.48420-29-ryncsn@gmail.com> In-Reply-To: <20250514201729.48420-29-ryncsn@gmail.com> From: Nhat Pham Date: Wed, 21 May 2025 11:36:09 -0700 X-Gm-Features: AX0GCFtgXDGcFnhZPDoJcbzmoW65Hwzramks9leMjiZTXzojzSJvlilAmNu1kE0 Message-ID: Subject: Re: [PATCH 28/28] mm, swap: implement dynamic allocation of swap table To: Kairui Song Cc: linux-mm@kvack.org, Andrew Morton , Matthew Wilcox , Hugh Dickins , Chris Li , David Hildenbrand , Yosry Ahmed , "Huang, Ying" , Johannes Weiner , Baolin Wang , Baoquan He , Barry Song , Kalesh Singh , Kemeng Shi , Tim Chen , Ryan Roberts , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7BFC840006 X-Stat-Signature: sahtsni1zmdz5ugi6p7xsqy9pruu14kb X-Rspam-User: X-HE-Tag: 1747852581-391960 X-HE-Meta: U2FsdGVkX18AcwC3d1XZO5lpaDhv+YeBpBfHtdNOkxv+f660RFeK4uksaCxkGmFKKzDed40O+Ko3e2FR0dyvCvefElSFvj/GYAgNN2MwzElHZ/L2pD8+YBO/MqUa6BLk53v8JQvhEP3flOzuCZFSsMg1TxwgLkKKXfjRTDwQs8px0bbZEKtPcDBB1NH5TvOjeDA7XBU1lUzDoikaUTCyGSnXxh1z8Dx8lUE1QqWBz2Z79qDEuEYdVIrVp2o79y0ncQD1z/TArjJ6INw0uSluGHda7kefU+ObwcCtM3MG2a7BUXLkp5VAfJ2RVIoWfFp6AFeJkOBeKBVeR/48vb/IHcCp+RCgGsVEyOG06jpd4hLlAr0KkRC99cftZVV+g5DhT+jr2Z8YbGzeejChVguTqpxDdFo3ycmP8Eq8kEegLdDrFk/HXcMcH4PvafSp9KXiyw2Owh7WDyOePr4qObiFVw3YgblzBcysqZCmXmpu6CQsx/jXreedkvsqSlzHcljekPgWBW/0s1UTRcViYlTSayIe/iZOpKvL3TKjNenrTk8/Cl+GShUmfDIZuRsilbnyW8cE5N7wLx3f5V+OxIQz+VO5hdSw7WYIdZIGoJeNmyTigT1aWyvpmT1gDlzuUFWpd1OiBt1v24U1izo/DuRPRBnMEM9RWE/ZD7klEnvKeoaV4c+lQeNmMGLJtQOaDB8zXK0w/psjtkDRo937guXo6hey3NjjkV4snZ3M1G2NovXVnewOOYFacmz7CIkbH6c46uEPUKwYDVMCRSNeOMpLVDkUfmlPAU3UhVVoXw1+kYD96PFqQYLgDRKGk8usxEBQfIkBLbmpudQTN2gXn+P2Fu3DHVyc/iHXTh5wiJ7Gg/48jvKHxnrzTOaJFOpmqzMabsNQ6QRHuI+EpvX2AxNSxaRWyPObWq8DjFVEjGWHCDvLkTESiOxyElmGHmNI2nKS2wKMq3Z9xcUupiG2mbP TZJXwzdF U+92twASFO15sodJT+8DbTBelLcZo55/9SBLrkox6jExbp63GMVde+1KBfyPyYfIH3TAdF9kXuU2FasW4GAf7CQK73Va4UJC6vWLjpAmJanvOryCzo5uyKIALEjhjSoMxxn7FOwT/I9OuEvxQKX/DwJdajgCPGbs1lIGEzx257VRDbamxCcJCoaKsxAQxH2pPqkL0FQhOYvHL0NkGqtUzFXl1XdNZXPh16SSQgoOugvnptInrr/ZYwmCtrvetxV9sabrHBs3NZaOoV1qY+Ha+/Nj023isl2rwXjnFws7+WwgjEIuPYAAuTeyQ4AM2+4jm6INsCfpIELvxicGS92W2H+ZSqkvqA08+AMKVPgubFNJAkWQWDSYpdQ0YeAPEO9rdmjj0pozSSVX9XXA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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, May 14, 2025 at 1:20=E2=80=AFPM Kairui Song wrot= e: > > From: Kairui Song > > Now swap table is cluster based, which means free clusters can free its > table since no one should modify it. > > There could be speculative readers, like swap cache look up, protect > them by making them RCU safe. All swap table should be filled with null > entries before free, so such readers will either see a NULL pointer or > a null filled table being lazy freed. > > On allocation, allocate the table when a cluster is used by any order. > > This way, we can reduce the memory usage of large swap device > significantly. > > This idea to dynamically release unused swap cluster data was initially > suggested by Chris Li while proposing the cluster swap allocator and > I found it suits the swap table idea very well. > > Suggested-by: Chris Li > Signed-off-by: Kairui Song Nice optimization! However, please correct me if I'm wrong - but we are only dynamically allocating the swap table with this patch. What we are getting here is the dynamic allocation of the swap entries' metadata (through the swap table), which my virtual swap prototype already provides. The cluster metadata struct (struct swap_cluster_info) itself is statically allocated still (at swapon time), correct? That will not work for a large virtual swap space :( So unfortunately, even with this swap table series, swap virtualization is still not trivial - definitely not as trivial as a new swap device type... Reading your physical swapfile allocator gives me some ideas though - let me build it into my prototype :) I'll send it out once it's ready.