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 413FEC197A0 for ; Thu, 16 Nov 2023 08:33:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8033F6B0423; Thu, 16 Nov 2023 03:33:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B2276B0425; Thu, 16 Nov 2023 03:33:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A1DE6B0426; Thu, 16 Nov 2023 03:33:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5AD536B0423 for ; Thu, 16 Nov 2023 03:33:19 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1CA27140C0A for ; Thu, 16 Nov 2023 08:33:19 +0000 (UTC) X-FDA: 81463152918.17.C4E78FA Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP id 175291C001E for ; Thu, 16 Nov 2023 08:33:15 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lMwU6XWR; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700123597; 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=2pdOAkIF3BrflhUJcHeCmAhhjIUw5doLroEfwG2OVno=; b=F8DlOp62p0sYmZ6fAr/QqOZBqiK2yblglq72TqX5MYBz6bI9TKowMbTOG2op3itUnTc64A ZrJHPOjPsu/lv49ZkRhKAD/VNIgQrcCOAoZ0okrDyxYweR1EcExmgrItJ40SeTGBpuAgqn 3zs/W8c2pHqg3MjR+aIimPoh3s1tbjQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lMwU6XWR; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700123597; a=rsa-sha256; cv=none; b=MAoPvpnOiVy7bDWRzTQr1ZNqaXadCmBiUEVy3oG9NewHJDdJfKjhGH74bz3HMtD3gC2Jgv bJdQc1r1rhtfUU3iPYgYg0Pz/3A6ghre9foeBmu7wCRK6l0gBo/QWFdgSHeQbTEMZqvkQP relTLjkBWGLevg/Px68PZ+NGdzhbd+I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700123596; x=1731659596; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=a6pNSoBHnMP71ZOfqHBa2nwHsEXWNsx5L+AMwWNcIXs=; b=lMwU6XWRNczZSUyu3BMlubp1GTgz5NUozsQrQg5MPOYr0NSIP88Yh7dX wRv1YRLWR7ZEV7875JA/piaYHV217N3fTZil7J3mN2lpk14cJwvT7bJxS ROQbOhfx2IhmV7gfiG32JvVZY+KW990LQbRHD0yVLYFs3PMdB8mx5gylr fM6olZauLTXVjt4vPojLj3mJ0J0y4KOvVSve0+Ktn7ShRU7MC8ztYsNNN YSj2nJvjY/GOX1ze7KsTdSJzl1zqZDz3qAkC/+i/gQSAg9K1KnWbWWuYM KZfkRePRtQ8AvlBO5SxxJk3CY8a927SdNXpm0V6wRkfFqfxTr0HXP8Ujp g==; X-IronPort-AV: E=McAfee;i="6600,9927,10895"; a="388209421" X-IronPort-AV: E=Sophos;i="6.03,307,1694761200"; d="scan'208";a="388209421" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Nov 2023 00:33:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10895"; a="758759956" X-IronPort-AV: E=Sophos;i="6.03,307,1694761200"; d="scan'208";a="758759956" 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; 16 Nov 2023 00:33:10 -0800 From: "Huang, Ying" To: Yosry Ahmed Cc: Zhongkun He , akpm@linux-foundation.org, hannes@cmpxchg.org, nphamcs@gmail.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios In-Reply-To: (Yosry Ahmed's message of "Tue, 14 Nov 2023 09:16:00 -0800") References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> Date: Thu, 16 Nov 2023 16:31:09 +0800 Message-ID: <87bkbudrqq.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 175291C001E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 5nfuus6ra8kdx8ofidqmf185a8gsd9sj X-HE-Tag: 1700123595-600758 X-HE-Meta: U2FsdGVkX1+QqQgfgPwPbSW46edSQeDQumFXKrQA2jkhDkNWsI3RAoe++ruxRUIb9tVF3ikEftooDon6ZHpT6uNAZL8RSTaQunqibd0ozalU/6Ric87+XK7mli+ZiZtem/ujKgcvzPGizsNSYOwaa1lPSb1NHKquKycAepX4j6lyC74b3RGPKX9tqxuk4dCOTrTBKqnMGaK+rYQE6dlZZMEKh8/l/xwoFuSXhUVMvJ5PFMj72Cj+dPH6w7HVtsigH3yX581W5Fv8VsB2wG0UvBiuwhSS14WxF+kbZR4cFSSRC4yCb5ATav06cEKmAQ5lK1vZB+ZUkbxmkc5wCK1N+CW2n9qJxGVvBYphWytjPg92yQvJldiox12VBfHrPk7jix4U+I8hf2ERgwHTtYo9qIQ06C8Re6Sh+QryCOleYxVYtNS2B7OToHss4kzfneeetOrD7DsRGuY2QP4rNtDU/BL8X6NeB6RBUBO/OaUFidfl5cMNt34qb3FrhpP1/bAmL7+PxiWmg1G7xojgqJlxyA/xIMw/vtpjQgo0spYdKOzjXAcM6k2D49ORaG73oNOLv82dq65rlMttR3wGqyD2aqFOeoMLE8j4ScF+qgxbD877AWqj8wgxVnlE/E9qld9AhNX3walC4O+znCg3ZKFUBvCNsx9JgMETsKMYeAqc1rG5SM6Bj+Nli+2/s28kNls4Uk/9C15zd+QAsKoWc90CtluZjHE9HyvO5ZTx2BlV5GAGF7PUnR7n2CMv9bSeMMM6xzh3/g3dbFrmZQ9wBQ45HhZlfqXfWaiKvJahSZ4D6KkrO1D3MWyBS8g2pwmHdu19OyKLq94SiwTc0NLv5EdQ1zeAJAY2wal1u/qzeVBkpXyEdzYDbXXgT/zjMU4hTXYBlLfByzujQ04dq89z300x9BZWHKkTcxqvvOiXecWOoTuP+LbgYALFjqecTJ7f/G3B+iXzXwS92TZ7F6NvMbr RzK0vstM bqocyxgtte5VsGludu0i4VryW68oFDZSMPGEtp/3SOodUr5Vs7ml5cCB+0wqvBcIf5qe/SkjJl4Q4YSmlGCYLw/so0kidoLeqMF40v3sUp0CjX6GXP8veBL9X7/eU8DGrwoZIJTCT9aGT53AvS2iUVjBN1jQ/ubZLlVH8VN8KYY+o8FqP32XB8G+cimoUA4ANzch9r6RBdGnnDlj+0ZJyZDsFR1pd7LcsHe5x 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: List-Subscribe: List-Unsubscribe: Yosry Ahmed writes: > +Ying > > On Mon, Nov 13, 2023 at 5:06=E2=80=AFAM Zhongkun He > wrote: >> >> I recently found two scenarios where zswap entry could not be >> released, which will cause shrink_worker and active recycling >> to fail. >> 1)The swap entry has been freed, but cached in swap_slots_cache, >> no swap cache and swapcount=3D0. >> 2)When the option zswap_exclusive_loads_enabled disabled and >> zswap_load completed(page in swap_cache and swapcount =3D 0). > > For case (1), I think a cleaner solution would be to move the > zswap_invalidate() call from swap_range_free() (which is called after > the cached slots are freed) to __swap_entry_free_locked() if the usage > goes to 0. I actually think conceptually this makes not just for > zswap_invalidate(), but also for the arch call, memcg uncharging, etc. > Slots caching is a swapfile optimization that should be internal to > swapfile code. Once a swap entry is freed (i.e. swap count is 0 AND > not in the swap cache), all the hooks should be called (memcg, zswap, > arch, ..) as the swap entry is effectively freed. The fact that > swapfile code internally batches and caches slots should be > transparent to other parts of MM. I am not sure if the calls can just > be moved or if there are underlying assumptions in the implementation > that would be broken, but it feels like the right thing to do. This sounds reasonable for me. Just don't forget to change other swap_range_free() callers too. -- Best Regards, Huang, Ying