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 1E2B4C74A5B for ; Mon, 27 Mar 2023 01:24:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE98A6B0072; Sun, 26 Mar 2023 21:24:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A71B66B0074; Sun, 26 Mar 2023 21:24:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EA9C6B0075; Sun, 26 Mar 2023 21:24:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 78D016B0072 for ; Sun, 26 Mar 2023 21:24:30 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C25791604E1 for ; Mon, 27 Mar 2023 01:24:29 +0000 (UTC) X-FDA: 80612933058.23.E0901BD Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf01.hostedemail.com (Postfix) with ESMTP id 3ECBB40005 for ; Mon, 27 Mar 2023 01:24:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="AQho/RJ2"; spf=pass (imf01.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679880268; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NmckgNzgIvwXPMYXApnTB/KnaMRLoVsYElzjeZrHNac=; b=33pwVW+xDFUPhyGkHgx9JxyIxqTlVFeopg/ZtaZgHPdthum2Ltb/2pfu5Q40p/gyG3YuL2 xPE1C47YFM0TO3Y54Rabd6AG9jlw9vAlSQng6HoNBdjWxjOkTsgbbm3EVluoiFZC7Us8KS M77NF/exKZGDbT4BebhF8wECGj9hjE4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="AQho/RJ2"; spf=pass (imf01.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679880268; a=rsa-sha256; cv=none; b=Fiwe84jOZdig0RiRSqAQpEyoZT/c2KlsaRSqlXyM6J1wwu5vCL8fwy97BxbpnO1/ZFu2S8 qO3HBdi5/mU/KzClGKvUk3a6YjFYYyOpx88ggM8bCyKJyTtpOnjb5Ax0h2Zg7cE+VgjsTz 5WE0sFEQxkupV05Qjs5tVMx06TmaE6I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679880267; x=1711416267; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=TJR0QU/Ru43jqZvL3d6x8p7gprWx2vby/WJ21ewgN1o=; b=AQho/RJ2Tw8+u6pBRJKMPE5tuNVB4iaNmuFAJORmxyQvmDVeHRTTbDoV nE5Dx0RoLsTQNVOAvXDiJNCXS3B3gyb4/J6t7i8MZ4h84cPEcpn3w3SyQ O9weCUqXagRj7o1LSdjZQmiC9DuGnFwqMa4+q2OzvJcvyv4kwnZmnkdez qQbj+12vUaxUiyYCD41Aeu14OrGRYT/HZHdqydrra1q4mIcdr4wDdYWPj wmIOvHmVbl7z2MreT+jd/1I2GtHYeVWnB1UoWDZnVjZP8AgoQfChZdiZm vFRDY5fvha4rGfSr2dw+upfNfFBxX4OsAktTh9UUfuWEKoPwlTFPtxp8h w==; X-IronPort-AV: E=McAfee;i="6600,9927,10661"; a="319810720" X-IronPort-AV: E=Sophos;i="5.98,293,1673942400"; d="scan'208";a="319810720" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2023 18:24:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10661"; a="676795100" X-IronPort-AV: E=Sophos;i="5.98,293,1673942400"; d="scan'208";a="676795100" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2023 18:24:21 -0700 From: "Huang, Ying" To: Chris Li Cc: Yosry Ahmed , lsf-pc@lists.linux-foundation.org, Johannes Weiner , Linux-MM , Michal Hocko , Shakeel Butt , David Rientjes , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Yang Shi , Peter Xu , Minchan Kim , Andrew Morton , Aneesh Kumar K V , Michal Hocko , Wei Xu Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap References: <87y1ns3zeg.fsf@yhuang6-desk2.ccr.corp.intel.com> <874jqcteyq.fsf@yhuang6-desk2.ccr.corp.intel.com> <87v8isrwck.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkkkrps8.fsf@yhuang6-desk2.ccr.corp.intel.com> <87sfduri1j.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 27 Mar 2023 09:23:19 +0800 In-Reply-To: (Chris Li's message of "Fri, 24 Mar 2023 10:23:24 -0700") Message-ID: <87edpbq96g.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3ECBB40005 X-Stat-Signature: nggb3ie3rn634xs3tit616pi47wqmoja X-Rspam-User: X-HE-Tag: 1679880266-652949 X-HE-Meta: U2FsdGVkX1+ALS11eEcdSt1rZP9bq1rVgiw8+EJzRyKuDNHC28g9+/tpbJQ9ZHoUlUMFgsmlB2srlEKwIxsQtc2DB7p1bub5bwZG50F3HEx/bJLwLZ6DBAhfd9R82QnJ5plLd8wQlwLYbfdTJ6Q5wC6FFEFSUJRF6Pjasig6W//CDcmLSBUun+sT/gqzO/wgJG2qbMb2gOWaRa0r+gbjFlCx4r6W1Nk+9P3PYHLDeVw9mBHN6skmL6IbBCF5/HLrmSXdms4w0Cjo0o+hj89MVTYigf/FMtX8hIOTlWAFRDnf/kLbDSvBFeZDyKcHgLS2RPjvyq6ZXoBtGVbR7r4aHbkyMQmUrrwOsRW/UT8Q6yBAUkX6h+hBOnzvTnV+0EAoaMOpwqhvCIEArFU+IjdtSXOgFl+4cJfE0a3my1PP7Zd8WkPa/pJnrgxyPeoDcvnWqqxyJsMfBsYzFkpAPZY6gqN3lVSASqGCxhgrRN8RG917IRgF5B2NKm128h4idKqnK8Ifi2SiySjXx+FcPpDF0b2tLiT9Ii5Ds8OyiQpTAKlx4/lrV4MxmR21KGyyzYmoZClDU9oJO55kB76rMwDanTT0YOW2wa0vCW+1XpKigf/5GMAKBmrVeQ95wMkV/C0/Kmdut1qny0Sy8LsCLAI0CdpnOdaVbtBj7qBKX9OBC3GiecWWmddRKbvZUi0RCFifQaT77q7+4FqXJPaQlsKBiG+E6U6XTtJYFK/8y3B+rIIqSIrHpL09bby9L1gSnjU3doTiTOcnCn8+m0viz+z+9vouw7/s1pb/MVV60aMRMbwuTtNO9n/ZsSGS0QJ7hJr84d8+cOIEUjnGBjjR0NmIze9uWpFw3fROKe+FpzRw3NT2kEZrwde6dfVO7U2EFWXlgQzSN611DP9GSLfH1/g/d15gaPXzs9S4TTEOIo9NDjX530STJxuGyH2lpY5s0OZ5/Foilk/hFVnNo/vUrOn ENMedrJd xLoFc8uiZ7J9DRBZCTWXHFh11pFy3iFr/lebElR0C+mrDO986/vbBPKH8xADfaWgetGV2d1EX0AweVpfy6ClwQOXRFUVemrHlsuiPetUEui0qQhDyffh8Dk6oZGA9o3kAVaEH9HIMmMxeVtw7frVletpRw5BAsqCWFfbbCHMwgOk/gEN6sIxs4l5N4j4oF1idBoyLUWlOhxPLoZ4/9kBHWAJeYiW/wKbzR1p3 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: Chris Li writes: > On Fri, Mar 24, 2023 at 12:28:31AM -0700, Yosry Ahmed wrote: >> > In fact, I just suggest to use the minimal design on top of the current >> > implementation as the first step. Then, you can improve it step by >> > step. >> > >> > The first step could be the minimal effort to implement indirection >> > layer and moving swapped pages between swap implementations. Based on >> > that, you can build other optimizations, such as pulling swap counting >> > to the swap core. For each step, we can evaluate the gain and cost with >> > data. >> >> Right, I understand that, but to implement the indirection layer on >> top of the current implementation, then we will need to support using >> zswap without a backing swap device. In order to do this without > > Agree with Ying on the minimal approach here as well. > > There are two ways to approach this. > > 1) Forget zswap, make a minimal implementation to move the page between > two swapfile device. It can be swapfile back to two loop back files. > > Any indirect layer you design will need to convert this usage case > any way. > > 2) Make zswap work without a swapfile. > You can implement the zswap on a fake ghosts swap file. > > If you keep the zswap as frontswap, just make zswap can work without > a real swapfile. > > Make that as your first minimal step. Then it does not need to touch > the swap count changes. > > I view make that step is independent of moving pages between swap device. > > That patch exists and I consider it has value to some users. This sounds like an even smaller approach as the first step. Further improvement can be built on top of it. Best Regards, Huang, Ying >> > Anyway, I don't think you can just implement all your final solution in >> > one step. And, I think the minimal design suggested could be a starting >> > point. >> >> I agree that's a great point, I am just afraid that we will avoid >> implementing that full final solution and instead do a lot of work >> inside zswap to make up for the difference (e.g. swap entry >> management, swap counting). Also, that work in zswap may end up being >> unacceptable due to the maintenance burden and/or complexity. > > If you do either 1) or 2), you can keep these two paths separate. > > Even if you want to move the page between zswap and swapfile. > > Idea 3) > You don't have to change the swap count code, you can do a > minimal change moves the page between zswap and another block > device. That way you can get two differenet swap entry with > existing code. > > Chris