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 4E8DDC6FA8E for ; Thu, 2 Mar 2023 21:42:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90F156B0071; Thu, 2 Mar 2023 16:42:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 898BA6B0073; Thu, 2 Mar 2023 16:42:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 760386B0074; Thu, 2 Mar 2023 16:42:43 -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 62B766B0071 for ; Thu, 2 Mar 2023 16:42:43 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 25F77160773 for ; Thu, 2 Mar 2023 21:42:43 +0000 (UTC) X-FDA: 80525283006.13.9D8934B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 7DCDD140015 for ; Thu, 2 Mar 2023 21:42:40 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cPrPkrHJ; spf=pass (imf09.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677793360; 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=D10rO7f3yqAo7iOfXhDriMvf7kovgo4qc5HN54/0+bM=; b=v9FCsytPUhSOZmnZC4WHEzxUouq5pEn78VDeHF4MJ4yiRb/AVNY1eCp5zykjojbYEMH6UN ctQKwxA46biUgmPpqX8iQWNMzp6C02Y+/JDubX5MSuBMJJNdI7WnMDV2+M02mT0dJ4zE/t ELmB6wlp/Np1CrZJpQHCvw2Fv14hBJ4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cPrPkrHJ; spf=pass (imf09.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677793360; a=rsa-sha256; cv=none; b=CiTdFmjplnidyn9FdK0sBA8Vdb1M2EVZQYkAiTk7rVmrgnSnIc9t4cqPxViQgwqaROtS8Y C3CEtk3YkhMurYvFsAx8ci0o3nN4p5Nx6raB2eeYN8yDSVK/Vf4zFFRQ3w8y0rU+XAewC2 YP8//ZxR6OCV5InuSm7+POPc66VsypY= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8529060B55; Thu, 2 Mar 2023 21:42:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51B7FC433EF; Thu, 2 Mar 2023 21:42:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677793358; bh=dT13BBxroRe7BZyiMmSe4b/oMeAejDwzDp+lQSrTiI4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cPrPkrHJs8psz2LWZ2yVo8gUmuFanoaT5dEbl6VVgNDhSt/wZ+mT4qqX9A+YOQb49 bvPib7yFgwgIVVP1w7loiGELRHagXt+RNI9lq7UfDzAf955vfrAXKxb7pUhBeZ7tTR EHTXlwMO/FxrRog9Ot41h/rpNdRkBwLiAWTmH+gRBA99kHl0dOl75op6rtES9BCIuN RwezdFP8cBzxacI+8wzBwYHbwCmGtIqlFGOVM9vdrFODBUn7U3nTj+nDzKCSO1sWBx CB27vjPAh5OMYrmk3RTkTxi2mj6mM1HZSxqviudFZMHslOiNiMgSg/aCo8QshKboNt SxgCCNCo8QqpA== Date: Thu, 2 Mar 2023 13:42:36 -0800 From: Chris Li To: Rik van Riel 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 Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7DCDD140015 X-Stat-Signature: pnebug58fp673p587zpcnsdq66c7nygz X-HE-Tag: 1677793360-909752 X-HE-Meta: U2FsdGVkX1+OGnuxoPriBrKJnXz00D8HTwumXI1cFAbNtk+Sy5GYHNUNq25mQ5pfxz5J+O93b5GgHEBYNdw/ssjpne1N/J7Ya6I07Kj7+sbFkjThcnD/OviDAVtFuaV8gAlhDl011yjn2i4MhLM6rCPVePiTN54EsLy9F529RKoPGERhCLamfRk3O+NH02sNjl8W6fm2wWFPYkCwcgPF6aeFsIY/1lkLdsVYdHu99K+DSzUxyBlRJrDfD9NY+LvIB7Id7dxKSF2RZUB+lXX4HLjs1tDo3Sz7AKPzZH0yJlsRw2L+ucD4fsUwDW+qlg4ta7UdOTQcLYBQnk5JzTRuda5mcRhpv/CQJku12KncR8NLkY7t71G3vO466XN8aKBrfU1aFjUwL8DHdQtJbwpvPhjSTCUd/exjAxfo8Dqk8izMAVlb4rCxIuHZUc0vHuVV3XDDWl5Bt1tMMZNuE8wBabmEFIWnN3W4oiqFe04k0ykjEoVgHjRRp0nQF9ECD+69XsOLTnom6YVr2fq/b37b05sYuYPQ5O8lGhTswq85Xa7jLVrBMtdYWFdjVU+hXITh6wN0BBCns/MwIgXOhng0QFTMMsrLNk9h+OQBvmjrFzpoalpZ+32CLSzzEgwMp7xfPat5v8H1p85VN1wT18xMxrcXO9I0EYdgTBmDilsjeGXdHkco7v1e7Dew0aEuGQD37maZIrJ8WlEUOWJuctQMDGIksY9lnPO2c2+v1LVxLMk0uT615KWkfuhoAR4Hi/Jq5wnwyqecM5MdR3Ew7wAT+zVTwAZJtyxgRAuooy/JQn6TDAOyEyqGBhkAdKj2Il+GsVVzUAfwPtzuKIbKlI6+4qSuXOjb04XgOzVDxszwasnaHumuF/T6G/iuGtrFem081VpFnVFcRLLewP+wxDaT/7UXSW2ax4QFHFDkrkiaqwVwroVcahgMmhoYrS8EiwTIDzAWcgmpEwJu6YJygPx FJkpzAk9 tA936/AoysIDhytDPSR4ehwq2kN3/mjn12xN+WtoRWi1lvCM/Hta+ZjG+LmaiOCLbYPWXTGob4x4BFtGXUIZHFRHImSWTtVUnW7eMPCwcYmuva53Ep4x2Oo4zLmxJb4ZPydNTfZIzcg8lukdAknIMONVm2o/r6nFzllomsf4ZqX3ppnwOsLUUiu0Nu6G5zT7AjMemEd+TPuKI6O9Eq7hZVEal+aDXnnK7We1tYoZI3D3bG4yqgvB5J8pH7LiDUblG0x9lnm9N1Msk0S4= 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: On Thu, Mar 02, 2023 at 01:23:14PM -0500, Rik van Riel wrote: > > How about we just put the indirection layer into the swap device? > > The indirection layer needs to be higher up, in order to allow > for easy movement of swap entries between different devices. In my mind this "swap device" has some upper layer parts. Maybe I should not call it a swap device. Let's say it is a redirect on the swap_info layer. > > For example, we could initially store something in zswap, and > then later decide we want to write it out to disk swap. > Right. We might even want to move swap from SSD into a slower spinning disk swap space. > This could also be used to quickly free up swap space at swapin > time, by freeing the backing storage (eg. in zswap, or when disk > swap is starting to get full)) when placing an uncompressed copy > of the data in the swap cache. We could apply per-device policies > on whether or not to free swap space at swapin time, because the > tradeoffs are just different between eg disk and zswap. > > Doing that would also allow us to turn swapoff into a simple > "load everything from this device into the swap cache" operation. > The pageout code can move that data from the swap cache into > another swap device, without ever having to look up page tables. I am with you on that. > > 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. The questions, do we have this indirection layer apply to all swap entries? 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". Again, "special swap device" is a very bad name, let's name it something more useful. > That might be a net reduction in the code over what we have today, > because it gets rid of some ugly corner cases. Great. Chris