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 DF16BC6FD1C for ; Thu, 23 Mar 2023 06:57:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BE266B0072; Thu, 23 Mar 2023 02:57:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 546B66B0074; Thu, 23 Mar 2023 02:57:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C0D66B0075; Thu, 23 Mar 2023 02:57:35 -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 293906B0072 for ; Thu, 23 Mar 2023 02:57:35 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C38E11A05A3 for ; Thu, 23 Mar 2023 06:57:34 +0000 (UTC) X-FDA: 80599257228.15.24D29EC Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf12.hostedemail.com (Postfix) with ESMTP id 021CE4000A for ; Thu, 23 Mar 2023 06:57:31 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UZjtd0Iv; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 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=1679554653; 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=VZndnfc/JsBkVHE/DbAnnrBzwmb52ur/znqZYbjVVGA=; b=efV27gzHmElpYiAfj/tB256pBCXdGvA+tWGoIkDAqPiHWBll92/WT8MeEF2pE9kBT++uRi Bt179lPxbXcWt3fusiHYB1/6W/OmW6txjTwlSht5h/wIR7tubce2krISa2lSgvSmkgDoib ppDA0vO5LmrAHE35Z7ANaSOKvcbBD3I= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UZjtd0Iv; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 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=1679554653; a=rsa-sha256; cv=none; b=QXwGRe18SXRcJSIB6x2pXZ3jkbOIhz5qkpOrX/GUObdnPZFHg7jdTs6fLYE4Ye9PIgCzul qfEn4DIIi+6PlYMJlWBObjAk8Q5VdwHUdSgLcyOkilrZkSUBJzU8QKWm9JQQfldCEGrHvg lqsAw3LVpBSiO0V4xVUebMAFnjnvKcs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679554652; x=1711090652; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=5AC7Mh/K4+HuwhQwmcRBOi7rrTrnP1qnD0pp5saIxwE=; b=UZjtd0IvnIqtNxxN7FeZaLXyArrv5r10K4rBntlKzjjcv5RtYKVe2jtc ff1vAepMRnbExeU6RZ33pETTTSQJZM5C2RiLv0+vBt/olcvRawpjBxn8p SovarSxcULzpwZQlqE3idVA//S0VrJ4fYtGbm44zBJG+Bio1r4YlENbvQ 92Uki1q82StW3IKFlCh8BCmKN8INUN8oLmS29Y72bYEBKOIjUCBiFxyHy cBwFcVaXafXnaeSjkbZ78Rm1NZNGlPJy7zWGkOmT654U6sv8BLPujte0t Q0XDNdlCcFoJ5WcOFnH37EV2AhXgXzmbXwv3/LCa0zCVHzUSBnJCNjOFJ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="401981228" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="401981228" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 23:57:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="682204723" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="682204723" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 23:57:25 -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: <87y1o571aa.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o7ox762m.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkkt5e4o.fsf@yhuang6-desk2.ccr.corp.intel.com> <87y1ns3zeg.fsf@yhuang6-desk2.ccr.corp.intel.com> <878rfothdg.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Thu, 23 Mar 2023 14:56:24 +0800 In-Reply-To: (Chris Li's message of "Wed, 22 Mar 2023 23:46:44 -0700") Message-ID: <871qlgrm5j.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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: udacgqqmzf7ybsr1gdhbwsbdxt4539wr X-Rspamd-Queue-Id: 021CE4000A X-HE-Tag: 1679554651-839660 X-HE-Meta: U2FsdGVkX1/0Sg2YQAFf3EhZ4zECvurEd6fgsx1WPMNAb08eGcYxw90M5OKt8KdgCyCwGn+hep3LFl/Zfb3Qtc5ilfLwEF3VBcy/tRBQj7L7QOWOtyrcj7nqmikcojQlFxR8blM7hHJAfZJSWzZMWM2cpHeP8x+qdhBkhIoSl1nuQ8W7ulpXWxOzsJoIP3O+UvQXB8b80mabz1MPUqMqGe3cl4Q5zSi8HTJEFaX3avCoOc2YeDM3vjHtQVRgFlDP/I//wByPI4grUu2uiAlNLAE+9PTzkh52Mf7qZVZGh1xObSrOcKVKhAC8j26u1rsgxklca2QZGy63x62J6qjXfcXXRyR6I1vWoqFi13BLJkCxyfA3/38cKRL1WMMqAk8ocavyOs8oDjdC+yuC5PmIisHc3fN8NCrGgZQ0wgT+hB2DXKKtt504csVOyJ3slJ7oKTRO4PuYZBUF2R1f8DsuBEjMd87NluO3MUIMhmrL4BqL4DM3Ok4OBdcMEAfjtuUjR9bDL4C2NBNIZhbCNBH+OOq/Utbp/nAVd2Ug5GPAWL0XGENy3KDA55tnPgikB6hD+bqwu0mzpZw8HpSjcRgcNhnrAYmJ4AvaJr++AEiColsC2SfpjQsLJShUCLLgwSQ6ZYpY16XQJBAhTRofek5PssrV1ql051EKYZ/xUGojcX5at6OXwHeu838BfnNlMWmLMqFZ0SoMca+mIFOGTQ1Qlf10QI0tRPd1vkPAZzmtFdzzHklJejarkOqhMhdCpaRZfYGwRg/o1v411jJSvkr/STXz7CkULVUusuwOx/SlYhw8Rr2NU+TRHW666dSAdAETqkKDweeCPko7ib39XO6PmyhLc5uvuW9xtfzqIkRVa+HfKFPVzzZxDSWeS105EWUOphiJc0tG4q+6JAQgOvn0O7mjN8vPhbvnQ5/MZIYLDgv4QZOU1/ePyjmlvW5JJJd/HbS2CnX2/K4OHTUbrzL 4NNcI6/5 3iGAFH9TPCBJ2yNg9+dTAxsT8ZwtpRddbbAVk2W4b70c9cJV/K4/ps5AGGkUEqj+4Sb55EGzhu+x/fJEG+48/KQF/KSVrzgGdFzSo6ZLJCDqkkqdgGWHp9rdHS0bEaDouPwYKG+D6pLIreasr6KL2WdomZ9NEsL7WdYlCYtTprg2Huhjsp5S4M9XbXwqcaYcnmIgLfHT63Uyh6HEtIYYWDJ2b9PCMWke50q2Hc/zad+3WXH/u/7Q2nsLMJVT8IJcxgS2sYSwlFeM161vd4kY3yeA9wxFL+H8zgiE8oAE6X7KmrE2rOHZjSenETBy2vs4X++Nm 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 Thu, Mar 23, 2023 at 08:56:43AM +0800, Huang, Ying wrote: >> > We need to carefully design the swap cache that, when moving between >> > swap implementaions, there will be one shared swap cache. The current >> > swap cache belongs to swap devices, so two devices will have the same >> > page in two swap caches. >> >> We can remove a page from the swap cache for the swap device A, then >> insert the page into the swap cache for the swap device B. The swap >> entry will be changed too. > It is possible, however very tricky. > > Let's assume the swap entry in device A has more than one user. > e.g. Swap entry A1 on device A is shared by three different > process. It is installed in three PTE locations. With indirection, the swap ID (swap_desc index) will be installed in PTEs instead of the swap entry itself. Best Regards, Huang, Ying > When A1 page data > write to device B, gain a new swap entry B1. > > We will need to walk the three process page table to hunt down > PTE point to the swap entry A1, change that to B1. There will > be a short time window some processes have B1 and other processes > havee A1. If both of them trigger page fault to swap in the > page. You will have the same page in both A and B's swap cache. > It needs to be back by the same physical page. > > That seems to suggest that it needs to merge the swap cache look > up somehow. > >> >> We can allocate a swap entry for each swapped page in zswap. >> > >> > One thing to consider when moving page from zswap to swap file, is the >> > zswap swap entry the same entry as the swap file entry. >> >> I think that the swap entry will be changed after moving. Swap entry is >> kind of local to a swap device. While the swap desc ID isn't changed, >> that is why we need the indirection layer. > > Due to the above mentioned complication. I am also evaluating > a design have the zswap just share the same swap entry as the > underlying swap device. > > The price to pay is one extra look up in zswap. That is similar > to the current frontswap. > > > Chris