From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B698E30C34A for ; Mon, 1 Jun 2026 17:49:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.44 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780336197; cv=pass; b=J1HxWCiTY2racCq7ZYeNqO0124DpLOYUmB4gyVh13UuxkFTvxUVNC/LMs6CAR7NUBWgvEWgWEDGnoJwGoOWEWwveG8M2/MgbDqhQUdU9uOIuL4bUwt5qjVADbH/GyxLzOVH09Zv/tzBMq938LeEQwMe18PxU/G+u35jbiwOPv/0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780336197; c=relaxed/simple; bh=MHMfGyIQO/wWrdZz2ftsSzh09DwykVOPctTnncxFW2k=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ve+Eg+FzSrSq9k3tOjJgCa4YojU0DftRl/1PFEyE9DA6whiJ+WWFbs2kM6hnqQwmjkpn4PUpPzB2SPyYjKXcFt+JS3ZUAb/GvxVnrsZVa1t5axjg+kxDa+Z2h792xV9xbDCSHKx4wEs/+Pc1B4i+bl77kOP1yBxAo+wWR3Q0QOs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rryOr97S; arc=pass smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rryOr97S" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-68c1653ea0cso4993714a12.2 for ; Mon, 01 Jun 2026 10:49:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780336194; cv=none; d=google.com; s=arc-20240605; b=fzTKXiVfjvK42BZ7gKWm65HOGMF0R348aWfB4d4Sg6YoKaHENtGPcOoMsx/sfJMdWX TIR6AbICqVIbU1qKxM0RDyU1rtU/twPbwk+eChtR0FYXP02z7gwTy6xzzaX1d1nbhSc+ ZbO/AYRlWxk71U7dmkLorThgVSaKNiskKI4xSoys9G611Z7L/nMivSDL9+F6pVPjCaz2 1dNSuW/lNLdAu0ON1oft/fjv1FFEjF+GgvSVRLnbyWHdtKhSvm73Zj/hywAyUJMpFGB+ aMQA+yGtd3ZSwdneQbAut7tGfwyW17KLlMA6GF/aU5KG/I8Fmj25FJkStgiLvC9ByozS 2lbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=pMR+vMx9phwXvzk3LCs0RnCPA1OW1RBGgb6+eYeQRiE=; fh=kg5tbGaEUsE7ykR8S/YVF5mII8Kr1VbME7FQcGRTYd0=; b=jFvI4FQbvVUCxL8h/Cu8nq2GfipBlpgzbjPDYUE6I3/7eWI5DdR9meeayyWIeMR0W4 GA0Ve3LbipvOkN+WIW4yLtLqJkuLNv2bxleC3+yrULPztiXzSvoOTZJeF57Pcl2ErSxB CqUxrBH6Z1SPnCzY4aBMfVvOwKdFYmCXVq+1pPe5rhDKe7vepLJsk0esnGZDmCFotoIG hwRkaZQd5uB4ojEzkBN/y6X3MXjsGFPZ3srKESKKIartpDWGOy6rleOnxTA7f0S6Mw6b +6mdOV8b9YJ7IBDVKhUO3VKImdj3J3OCJJ36WM57k/4qcTsjxO1L6jDN6oxJLM2nToyQ lOMA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780336194; x=1780940994; darn=vger.kernel.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=pMR+vMx9phwXvzk3LCs0RnCPA1OW1RBGgb6+eYeQRiE=; b=rryOr97SQy0Yvp2+DlBXsOoeF8EjhQ/KHkErallpDjCJTM8vVvnrxje8waUS3RSM6W K44IiWvhr+V7Mr1GrVuyd0oPesAgAbYIEwnpHi4ZUzoD45LioXHsBw9NsL+heiwigq4Q jDS7J1LfYzKtBTbBUkElNuXKSFoYll0jTvdQ+h1Y1QVtLGUek+o1BsBc8nxV0CMb9q+f uSQgTgxyE327kQkFtC4U9+JNVT0j7XQQ+aEzSl5wP/FhIwJxmfqHxax4oX+3vUO4HcQ9 gcfswYK4PLHucfo6VsL0zt1lYOWydWR49L5Ioiu/uehdq9XGLtyM+xwnzUkRN20QnWVe CKhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780336194; x=1780940994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pMR+vMx9phwXvzk3LCs0RnCPA1OW1RBGgb6+eYeQRiE=; b=YMlBsOgWu4+/zNLzXXOYfUL8y/N8pxaug4oUqAAHx07gsvuWpazdQv/dpxdBKwdt6k gwGV2DVYPAZrjnUDnRQiQkK05bNasbJdqXqB7HnsqWXV+vlK548UHPscnlqfXBgF3Ll2 YxnZxc5nzXziiFDocnQ5PWHmoS2JqjYiYWhOjdmGEgBaTzO4MepzxQbC4DLCx9X4HEfQ VUxqVrVlSJpVkgrFHX5z8yPsuc1J9cJUZ6FAPVog+kdDjyd82wnux2uWBwVle1eHtAc5 /NRv1QcRLCL97curqIVlZmh1jevpVv1RVlWOFju92v82JPPcAFHIFQTglVoZ/KJGI9sX 2WPQ== X-Forwarded-Encrypted: i=1; AFNElJ9X3IqFubWNO1Ty5RNiPc/ump6egAviHiGf/KWTxCqN4nX2uBPcZ5E+8fvdLaRmO2gKYdxH9N/1hGlNxSM=@vger.kernel.org X-Gm-Message-State: AOJu0Yxf6LtpJ1B7b3u/3iocD3iIdggIIEBAx8z9cb6S1LQRVOBo5mSb ALbVPQiEjJJmv+TPhF116E8X/b0wwgmnSgJioFTu8qCNer78r1vWtKphgCuXl/O7mFy+2sNAvwP d4dQusc3NbcLjPpuzHf1q4fedm3WhuBE= X-Gm-Gg: Acq92OGl2Mr4cHFkIldjaZIN1ln+z4vtVVHbljgvBPzd1aGqCrabNqpF4SP7XBhAa19 DQKEqgFbAVv2BM3GgRUiUhozlj5AFvd2DiilTLLCIGugosuihppa/iROWunuh85hUqZ+1YJsYrP N283RhFGkfnv+csTCU7gsIw4s/HVc+4k/OV8T5X9+WUUjVx0roJnP/Qwl0hrQYSZkrl/Dxyp8FM +eZ50958cCQOou7AbZW+TsNX3CEhBTlCfuwqKdHtrngGTFXvrLGDPIAqmtserSkRG9m5IAMUbdi DvraBnCyy989tn2Zlz58AKhiUcj8p0bdCtGc+t83aFN+gslOiHc= X-Received: by 2002:a17:906:1ba9:b0:beb:e13b:b3eb with SMTP id a640c23a62f3a-bebe13c09c8mr420086866b.9.1780336193926; Mon, 01 Jun 2026 10:49:53 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260528212955.1912856-1-nphamcs@gmail.com> In-Reply-To: From: Kairui Song Date: Tue, 2 Jun 2026 01:49:16 +0800 X-Gm-Features: AVHnY4KkMWDCgqvQ0VtgzLPCLTVcd18CUg6LbNn4WT1rDML5IaDfG1WZK2GBXNs Message-ID: Subject: Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition) To: Nhat Pham Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org, apopple@nvidia.com, axelrasmussen@google.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, bhe@redhat.com, byungchul@sk.com, cgroups@vger.kernel.org, chengming.zhou@linux.dev, chrisl@kernel.org, corbet@lwn.net, david@kernel.org, dev.jain@arm.com, gourry@gourry.net, hannes@cmpxchg.org, hughd@google.com, jannh@google.com, joshua.hahnjy@gmail.com, lance.yang@linux.dev, lenb@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org, lorenzo.stoakes@oracle.com, matthew.brost@intel.com, mhocko@suse.com, muchun.song@linux.dev, npache@redhat.com, pavel@kernel.org, peterx@redhat.com, peterz@infradead.org, pfalcato@suse.de, rafael@kernel.org, rakie.kim@sk.com, roman.gushchin@linux.dev, rppt@kernel.org, ryan.roberts@arm.com, shakeel.butt@linux.dev, shikemeng@huaweicloud.com, surenb@google.com, tglx@kernel.org, vbabka@suse.cz, weixugc@google.com, ying.huang@linux.alibaba.com, yosry.ahmed@linux.dev, yuanchu@google.com, zhengqi.arch@bytedance.com, ziy@nvidia.com, kernel-team@meta.com, riel@surriel.com, haowenchao22@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 2, 2026 at 12:22=E2=80=AFAM Nhat Pham wrote= : > > On Mon, Jun 1, 2026 at 8:56=E2=80=AFAM Nhat Pham wrot= e: > > > > On Mon, Jun 1, 2026 at 12:34=E2=80=AFAM Kairui Song = wrote: > > > > > > On Thu, May 28, 2026 at 02:29:24PM +0800, Nhat Pham wrote: > > > > III. Follow-ups: > > > > > > > > In no particular order (and most of which can be done as follow-up > > > > patch series rather than shoving everything in the initial landing)= : > > > > > > > > - More thorough stress testing is very much needed. > > > > > > > > - Performance benchmarks to make sure I don't accidentally regress > > > > the vswap-less case, and that the vswap's case performance is > > > > good. I suspect I will have to port a lot of the > > > > optimizations I implemented in v6 over here - some of the > > > > inefficiencies are inherent in any swap virtualization, and > > > > would require the same fix (for e.g the MRU cluster caching > > > > for faster cluster lookup - see [8] and [9]). > > > > > > This could be imporved by per-si percpu cluster. Both YoungJun's > > > tiering and Baoquan's previous swap ops mentioned this is needed, > > > and now vswap also need that. If the vswap is also a si, then it will > > > make use of this too. > > Oh and the MRU cluster caching I mentioned here is not the allocation > caching. It's the lookup caching, basically to avoid doing the > xa_load() to look up clusters for consecutive swap operations on the > same vswap cluster (which is the common case with vswap). For v6, it > massively reduces this indirection lookup overhead. Performance-wise > it's an absolute winner, just more complexity (because I need to > handle reference counting carefully). Ah alright, that's interesting. And I think we can keep things simple to start, since sensitive users is stil able tol use plain device this way. BTW maintaining MRU is also an overhead, I'm not sure if the lookup pattern always follows that? > I also just realized we'll induce the indirection overhead on > allocation here too, even if the cached cluster still have slots for > allocation, because we look up the cluster (which is basically free > for static swap device, but not free for vswap devices). Might need to > take care of that to maintain vswap performance (but it will then > diverge from your existing code...). That part should be indeed coverable by the si->percpu cluster though, I th= ink.