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 DD670C678D4 for ; Thu, 2 Mar 2023 22:36:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42D6E6B0072; Thu, 2 Mar 2023 17:36:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DD206B0073; Thu, 2 Mar 2023 17:36:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A5D26B0074; Thu, 2 Mar 2023 17:36:39 -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 16B456B0072 for ; Thu, 2 Mar 2023 17:36:39 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DB3A21208DA for ; Thu, 2 Mar 2023 22:36:38 +0000 (UTC) X-FDA: 80525418876.05.8161E78 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf24.hostedemail.com (Postfix) with ESMTP id CDAF9180011 for ; Thu, 2 Mar 2023 22:36:35 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=none (imf24.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677796597; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=ul6PM9CZ3N5yQKa6yryzOzmDa48g/XJ6gYWAdWUnE2M=; b=LY5dUpSRyOfAlNPxvQWtWpf6H/7Ia6UaJpas88A94pl+Do4HJ7BXws+qfqQ4LkCnsXWULc jQj1D9gFyMczzlalRVEVCmUksyULuypOC+gLAM/lmBgbcgQeVSaLAug190gGq2dEuOkiNK IW3V1w4WUGlfNNIhkqwK3VUajPhtUuY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=none (imf24.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677796597; a=rsa-sha256; cv=none; b=jgs8LgRirdF/COSmrHPiil+FW7NsALcCTh4jtSjqLScSVooSguTbw65Ki0bOceTw5bWrod 9U1YersONkL0R4IRdj8gdQZiOiHJdIM0GBR350GJf9nyN/ZD9Im+8sdhKE3AH5RNP0cCvN 3dzQ06AndxoB87KOekvaoks8uVUupC8= Received: from imladris.home.surriel.com ([10.0.13.28] helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1pXrXB-0007EX-0a; Thu, 02 Mar 2023 17:36:21 -0500 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap From: Rik van Riel To: Chris Li Cc: Yosry Ahmed , Minchan Kim , Johannes Weiner , Sergey Senozhatsky , lsf-pc@lists.linux-foundation.org, Linux-MM , Michal Hocko , Shakeel Butt , David Rientjes , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Yang Shi , Peter Xu , Andrew Morton Date: Thu, 02 Mar 2023 17:36:20 -0500 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-aJX7XeaA7eNAoBGQEa3c" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: oc8diro1zdkx6brmfmjt6t11tfa16d8p X-Rspamd-Queue-Id: CDAF9180011 X-HE-Tag: 1677796595-308755 X-HE-Meta: U2FsdGVkX1+WlijmNClSPhhXOLG3s/2UO9uTHbspgpXGMU/3U4ANXjkJZUMfFk/R9NZ8V8jvv4uumZtQoxP/+GVIi/UuAeqUGouUY4OiDYrkFq2lxWBxIaO7ZiLrlLjFj+av7mokRf+TCaGatAQvu9bfWIgn775ZvNt7VEreoHDbpA9FzKvRIVpVzASF4JnSZVMQyqTd+R2HCVzfyRbknNzkbHGan3AV+nBuYMizB18RMCBE7wkRv7JhytZa6cbqsMJ168JLGrMSFUa1mi5h4IMd6KCS4FFPCX4t4xB0kLwQWSarNrEIHhsV7hrlzLkegID7gV67CSBV6PYR3RSoFoUTe9pVbVWorpDHTr0GzwZxvUkZXlQwwly/7ex9xnhwGmmUH3KTB9Z0ImGXpgnc5bjhlJfB5w4t74HpWWm9tT9yBwZm+5M2Bpi3fxRe+u8ZWTqow1zzjm1F9+9zIO73IUXaYVnP7QOOOHg9SL2eUNqs38OTUjabu/UnF9pKKUhjFgA5lXJ4q0k0F3HLkR3BrSs8NSBWBGX4uVjrv7pXPbgLzZ7Q/FQ9E78ZiL4KSJYy3jlkHGsISn8If8npnGnsE1HLKmc/1EIWYCkeJ1P1qp0M0Ob80TSCsUX3FVyGIxjP2iKgjcNO3eV4sgGf3MiCpd+kE8PrEJfDe3GAeu0eYHdDxmdn3YIMh3KqYE35T5u4frLZwOuIBv0HKUuQjfmASB+cjy8t9pwLYWPrBNuS+JhQIhC3eEMbcCMmAnOZiukbz7IqirfR728LIM0b5Jhf/ytz1Fw2c3kP3Z3Uoi3+pwEr5sJ7KxVEMqIXi0uZCpIDRNznxSWm3K4DdT0SYjH9UCsYRybhdCUvLISKLw5Bb57UGFZGYHFoX3KYDwU48aq0N35TCjffKKgZPIkZCh+JLpxb1sxXEWxqxMT5GlXqEEdJrjLcz1Xm3eRXBt34kgDKWSpot0AUwm85yr4jWn6 oeNJlpEH d4FluRtRq0nR5AsW8BsMBbggPflg3xnUQZ1VpIAueloiOhlR8bJVEOunYsXu8NEtFpFHqNPPwplrAFTK9IpKaBQRFNtS2OWX2qSI2tEz90uLLMvJDzcdJQPX70VjcHM48M3z/3y4roA2YskWQz5Y/bqhjTzgvKTjYej5jqs/lB6J4RZ8lGakWXzzkLF+nETZXAGd7uUi+LeKSnDOamxEItEkJNUMalmlEy/taemGtXmCyNJZvqfyjW1m1bGvdTibEng4qHo0tCzUHHF+IQ4RwYy2ozL89HMrHS0r2XpkS5iBqMPGZma4tLeLRIxRl2e0hkzdF31MTc4Zzf04BW7z9oNTKNsxt4XtNAs4mT/2gd3ksQE4= 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: --=-aJX7XeaA7eNAoBGQEa3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2023-03-02 at 13:42 -0800, Chris Li wrote: > On Thu, Mar 02, 2023 at 01:23:14PM -0500, Rik van Riel wrote: > >=20 > >=20 > > One possible implementation might be to have swap page table > > entries > > point to a swap address in this indirection layer, and the > > indirection > > layer can be an xarray containing the actual swap entries > > specifying > > at which position in which swap device the data can be found. >=20 > The questions, do we have this indirection layer apply to all swap > entries? >=20 I believe we should have a system that tracks every swap entry the same, data structure wise. Otherwise we will have two sets of code in the kernel, and it will be too easy to get corner cases wrong. > My small tweak is to limit the indirection layer only to non leaf > swap devices. Then it is actually very close to what I am proposing. > Just your "indirection layer" is my "special swap device". >=20 > Again, "special swap device" is a very bad name, let's name it > something > more useful. >=20 > > That might be a net reduction in the code over what we have today, > > because it gets rid of some ugly corner cases. >=20 > Great. ... but that won't happen if the indirection layer only applies to some swap devices, because we will still need to keep around the crazy code to deal with the swap devices that don't have it. --=20 All Rights Reversed. --=-aJX7XeaA7eNAoBGQEa3c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAmQBJOQACgkQznnekoTE 3oPY/wgAq2veS7K/q2ZnBiFhc+LN7f7KQ9TwcPDV/q1kjGRcjvut4f9/D4CR955B Pvud9jq0fqITJBnNu1ExKdv4Y7IwvWVbMxiBnEKYB5s3Trpo5CTZXJp71WPWuLTn FRDUoBvPr220jyOUFU62GQcactpOEfZDD0axOqMmN+EaxEwHtLjrkblzrbuQ1Ac9 YPJ9vJ6wecEVo5j1HC9Lr9pf/GL6MUddhuaLiLmdN0gWQiXhbZCtXGKR629KT6WZ z7XtQBhdtujYuzCsPDpp9as7m5NQApAGEdJSYRvVKMY8dQRrbXjTcwUZ5ViCGW4Z jRQsFsI8J5Skzdmr3FrYVGsFRDYBNw== =4Ktv -----END PGP SIGNATURE----- --=-aJX7XeaA7eNAoBGQEa3c--