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 33C60C678D4 for ; Thu, 2 Mar 2023 18:56:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AF2B6B0071; Thu, 2 Mar 2023 13:56:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 638AE6B0073; Thu, 2 Mar 2023 13:56:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FF0B6B0074; Thu, 2 Mar 2023 13:56:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3A5B06B0071 for ; Thu, 2 Mar 2023 13:56:30 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0423380F73 for ; Thu, 2 Mar 2023 18:56:29 +0000 (UTC) X-FDA: 80524864140.18.6F5169C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf17.hostedemail.com (Postfix) with ESMTP id 1BCE740004 for ; Thu, 2 Mar 2023 18:56:26 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J7AXlGQC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of chrisl@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677783387; 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=r/XDcFrWZ5caEJziyt8IPpqfneuX8KImTcvds9zYcN8=; b=gLMBCvqEa9e+qyX/pkpVm3aE8I5F6VmzPKIpi6nNcclkh/aRic4bcvaMFoA5B873Q48nli aLeIZ/h2LG+C0TvPLKFTVlnPZsfah6yFJzZYyH9GMxNyzj2GVMPoQYWtc5CzBKeORVA4Fx FlweTg6FpE0SBbrA3A1CtdrTqtMxprM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J7AXlGQC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of chrisl@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677783387; a=rsa-sha256; cv=none; b=ScIZbNDVrUJzj7i+Yz9geqx6Y/OFhrzrXcIZRLW0TKvB8Z14qHObHNrsehHPyQDhdkvJCF 0pqu6kkDz9incsbMs9ViVlCF6e8oBxqMi2ghS5QExsVJB4PUftUXfvqyF7TIKCfMo+gckM Ls3raJpOTBTsUSTGI2uGgkIibx2sF2w= 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 ams.source.kernel.org (Postfix) with ESMTPS id 258F8B81440; Thu, 2 Mar 2023 18:56:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25AF5C433D2; Thu, 2 Mar 2023 18:56:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677783383; bh=Fkf+jWM/aca4YwaKkqo8mEJd8G5F4PjNvyuztrzRu1w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J7AXlGQCKKgH4adPO6ZhgIEQyZVPRLZQzS38p/3IAFqx1DP6Wl8h1EXoZ2UEegrJ4 nBmRqwL48dXycQAitCTbNCtncrV1KLeOIHg0KJua6mIPOR37bWMTCV/yawF8kZljwz ss8HjWHYJZjKO+zl7YuYzX0X9ZOSW1wVC5ZSDn1sc5pU0DWMnyYwd9Jbu+nNDoh9jn k1GV1qy1Ebjvj37WTENaxZYReYzotJPV8rb+Mwpm+3bqInXNhd3Xm+i2FvI4E5vZKK V1bnY1u03C+b9bM+guW6JAMGftnMVMMOP+HzcVQ234muNvq83cZb5aQjzFHKjnLZ3j sVTYVgz3ILe3w== Date: Thu, 2 Mar 2023 10:56:20 -0800 From: Chris Li To: Johannes Weiner Cc: Yosry Ahmed , Minchan Kim , 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 , Rik van Riel 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: rspam02 X-Rspamd-Queue-Id: 1BCE740004 X-Stat-Signature: hnouydecoau3tj78wdfhxz4tawqc6yp1 X-HE-Tag: 1677783386-160057 X-HE-Meta: U2FsdGVkX1/lmLJwwVLW/ObZ3DFdE1+dfWoTbHsxO1ScYYU5ryKGW0od2kHsG7OJK5noSeqkOdQ5YOgKkvicjmm3fcuwMAjEDBZVHUjAOHNOzQpge8usnUT5tBPiKseskDetIEgi3kRhHFbNx9yzovC1dX+6UkX7qS+YcocBfxoM3nsd9ANQTNuQ6wIlXGRzVWRA0xNbBqLPny1r5rFTSfZ2Ml+77LSFoXXa3ymrdWYjVmnH4dhgg7ufSUTPFmn0sATSnxxm1Rvn6ghWnQsIEZtBlxHrT1GNgY2gihJFQsYTfox/1YVp2B3XdOtd8DbognGqrdARmrXbQmdlyPv9I3IY48bdUg8S0frHDHll87BcxQlpFEbZWeeiqa11mJHqC3jr4q+oHR0uDxCSyEOFYi3le2LA/hByZIyrKMqGFUvQTGFyvJNh8DNv/mHhKe4MdA8rYeA9fuVfcvW7xzd79s99SH+HQ8ybf2d9EyUpv6Dd+pF5JnGEcHGpBKwRxJV834mAsdwnEnmjJpQzS/SzjE8iipbn08sM1vK8aFVBFt5eEK72vWMtNtic4H/vo4WXZ70Zwv6RsPTagVHny5Xlk26auJciBO5JCdLqLep+49ug1O6N50qVt7i90hA2/So8jN9xF93ka5iMr8vF3UmoOCBIHz65D6eu7j0iOi5HxiSH8nr40uHV7gHllOMfGvbCbMeq1Sb9VTv2UFJTpzTtwlwKNpAD9JievpxJ+eO+BOa5nDHE75NItedo+jUpzuDNikZ40+5Jwxut07WJq5d76/+MZCXyjw8NeFy0wDf+AjFnKBgDiJ9saQiRnPFFmcPkZK5eX0Hcm4QvW1pje6ovCGfdhqCp+SsA0GQPjYbmXXvvX5/BJ2eR3OpEKjaz+zZwRrqsk42sUspOzYZiuFvyXWMHsavLy8dLaUQGT42PGq+DM9r9bhXBeOkj/4pqlRgTVdZpwdME+bEF9ihze2c aVqP9hMA MekpxguSeZUTtizODV8kDY8qDiQVmg3lXel0sTpdzr1NH3QwYbW8klco4FfMfHPrFKgjIldTylVKctjkFk9kp7ueyaB3qYpFpq1qV7Y+/xq0TODkOzo3S89gcsaWHhuylPMKk59hxSrf9ZmMyJRyxqvcRiNG9rxJNlskXqEq1glAxK0HVyjWrYyOiAQE5z/maG+KifUrsL3TNlL8tojn5UAF5D4cpeFKSrvN/l2eiSruS4m9LRShP7YeDmqhtOGEpZjNPs2tBXeLmLEA= 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:15:32PM -0500, Johannes Weiner wrote: > > The common swap device related operation can have some swap related > > swap_device_ops function call back. e.g. get swap_cout.  > > That way, obviously there will not be much memory overhead for > > the devicethat doesn't use zswap.  > > > > The zswap entry can still do something similar to your swap_desc, save > > some pointer to its nested backing device(normal swap file). > > That way the swap_desc overhead is purely on the zswap side. > > The problem with that is that zswap needs to be able to write its cold > entries to flash. If zswap and the backing file don't live in a shared > swap id space, it means that zswap writeback would have to allocate a > new device/offset tuple and update all the page table references. It > would impose the complexity of swapoff on every zswap writeout. > When writing back to flash, allocating a new device/offset is unavoidable. Otherwise it means zswap will reserve/waste a device/offset even when it is not writing back to the flash device. Update the page table reference can be avoided. By keeping the zswap entry. When lookup the original zswap offset, it knows that the data has been write to a flash device, it keeps a pointer of the flash swap entry, returning that instead. The mechanism is similar to the swap_desc Yosary description. Will that address your concern? Basically the indirection layer is on demand. Chris