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 3F320C54E58 for ; Wed, 20 Mar 2024 14:48:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B45156B0088; Wed, 20 Mar 2024 10:48:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF4416B0089; Wed, 20 Mar 2024 10:48:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96E746B008A; Wed, 20 Mar 2024 10:48:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 809E06B0088 for ; Wed, 20 Mar 2024 10:48:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2635FA1C75 for ; Wed, 20 Mar 2024 14:48:27 +0000 (UTC) X-FDA: 81917698254.08.04B5385 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) by imf19.hostedemail.com (Postfix) with ESMTP id 4AA5E1A0020 for ; Wed, 20 Mar 2024 14:48:25 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N1zuKdfn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.221.182 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710946105; 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=/ltmvM0w70xtErdmc5CdiNk2BYEMlEM19F2i3B/Nu+0=; b=3yPzYauhC/WhWawmjQ1QeAPcjEgz+p0u0Bnv0RZwi+mLdBCBEpVdgEllxsAmKYHSKUwZd3 3sfD2NYnmC/4mWAebeg7XMy+kucJ4aIbt2A8uAqF8uTYP64oymzu4v7P+KTI1MEPp+YBwX mrFX64mY5kyBUfDj+9dyzJaNcJEYAUY= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N1zuKdfn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.221.182 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710946105; a=rsa-sha256; cv=none; b=yRmlqyStorKF5wG/edPUMz3EVXKPyrFWzQdn4NrTxjET2JvadYpWY6JYlSdpB2Jex7hkXF YqqeroIzjvT7lQwuR3InuKcrzgA2YREsiS7Mo7QfWdn4PCcwqzDWf3bX6G+jK3fTxYDpFr ++se2GkEp/bEc+Ur1Q/YCl3Ts82JXQk= Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-4d46c4e1578so910964e0c.3 for ; Wed, 20 Mar 2024 07:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710946104; x=1711550904; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/ltmvM0w70xtErdmc5CdiNk2BYEMlEM19F2i3B/Nu+0=; b=N1zuKdfnKG5JY3Nm2icuewvL94vwcpYeWDTZNeNLIDREfYTF91SFjW3WwOGJGgcEKV DaRlk5cFPMXMfsc11DYJ0XIX1tmwRpKPkl4/PMhrsAnqy7OfGGjhRzV8lGOQhDgghFkQ RC4vbEaEiC0/FJx1WXtrFhIWi/maVX4mrJtJ+uZDfKDHc1TlJOwV92GZLc6Majg5D9l0 njzikkAO7gg15/19cQd7+cedIY3q75QMDoVh8jPTZ95+L1BUPmuunTi5kuiNs4ETkr+w 4gQ96/f/AyiLMdGfCecrj9dF4nN9g/XqZ0RNj9tNRem/7T4F4f+3R9fnf+uHLRbGoNwY n4cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710946104; x=1711550904; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/ltmvM0w70xtErdmc5CdiNk2BYEMlEM19F2i3B/Nu+0=; b=MF52hGXXJnbxasp8n4+1XIxkRr4CcYj+3xFz7M9NBdQVKuy7AHdvHib+fkQ7w6mceg lCn7OrPRopGhqV1FW+j9ULD4rLPbM7spIfIcroqZVkC7m9saYLAkksoh6oqYk8S56ggG SmLW+dOFVeSDb0WWIAths+FIDVUVZlMdGMWZVxsmasGhBpjXuxmPv1wRIv/8xPRkt4Ca jnaBfYDsXWnGQoFql+arrd17OAmXwuNRF04LArRWWc578Uyk6e+IzX0DEQ2+sX6/NwRh t7lVDsu2a3punZzIQZgn4W0/lB+jYiu7QEphfNrOzZX2c8pQIH4Wcg6pDjWJQ6JEPkeL w5mg== X-Forwarded-Encrypted: i=1; AJvYcCVpDreCRT0h6bcKiqQeYnWn+qrIM1oCqw515rDWbCpZUl0s3EeaHj6LyLNDAaCfyQ0qsmHrmPWrLBPFAz7PfZrGzE4= X-Gm-Message-State: AOJu0Yx8vIZgwHhvvu1ciUvKTVD9QRpt58yOYpu6DkKM0DnngWyCZM/w zXlKDEQAvaQFAlRD0EyYtDmOpLr4wVAM1L69FeN2J0Oa+QBxx5Hmp/nGMN49abRJl7z5ZRF6v/U HjWQq2CWecRfT4Fk5Pv3L38gia7A= X-Google-Smtp-Source: AGHT+IFITGGcejv2uDTIH2avPNV8ieyCB2ZuD2EEw8Fg6E+sCuFlLinZLiBr2qVxuFxdpYc2yF+Wx6NXvulopF1jqy4= X-Received: by 2002:a05:6122:2514:b0:4c9:98f8:83db with SMTP id cl20-20020a056122251400b004c998f883dbmr18719446vkb.5.1710946104139; Wed, 20 Mar 2024 07:48:24 -0700 (PDT) MIME-Version: 1.0 References: <20240320020823.337644-1-yosryahmed@google.com> <20240320095053.GA294822@cmpxchg.org> In-Reply-To: <20240320095053.GA294822@cmpxchg.org> From: Nhat Pham Date: Wed, 20 Mar 2024 07:48:13 -0700 Message-ID: Subject: Re: [PATCH 1/2] mm: zswap: increase shrinking protection for zswap swapins only To: Johannes Weiner Cc: Yosry Ahmed , Andrew Morton , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4AA5E1A0020 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sfy5y9jaraudorumqtu5hxquu5c3ybgf X-HE-Tag: 1710946105-113575 X-HE-Meta: U2FsdGVkX1+25100yJIcmOeE20ViIG0WQd1dTC0ABKdHKUdCwBYhZTvems+WuanI40z+WZYEcKk4ZN9c3EBlrxgfJ6kC8Ug5ZCRVHpwrQ0aisAC11DFo2vCVYjV0iztgC7wOSEMsT7z1lnspLwE9ES5W4+ihBb8bgwEexbB7r8GhXEnnVug8YKYhCydbkU/hzqpHblX/QfjISnB86znPqN1J2zdraZhtxaQ/vb3lSJpVyAZBzHXuq5QdcLbDZvcWb8gqhgVvA11oF3Pbv38ikoREQ17j72NhiGngIYjJaiu9bq/AlLB4lZM3gTLF6Wl1QuyKb4+Z7wyR8SC6uuKWP/ZnX/ZrqGz8Cutblsc7ATNKHrXAXhlLIqQBAVmrfWo/dL6tqOzoU1oOiU431RvGOedXFEOgDDBif0eNe0xwLFhgc6B8mTCqog67Jkz/tS6od3gU/I4WsV0viN4nl2SrRHS/ko+0XS3ynduQn9x4SvzyojQydZBgXOcjLKV1l2ffViV6t9p8dYFBo3IMc8H3oEEFTjZXk4FSLgMKIu+oA51AvAdJfB7As9iSPjkJdZXem2XWaSrMl1q6rMC83LIA0+QhU7X2z9hesDgHfvE0PBoz5Ujmn2hCDIW5MluCpr6klkOnmWCCAjZRaxLjfbjAXmb8uPvhac2D+/dxKz/HQswK3kuvS53UpsNaC0c9IRnxLwNwy4cI98CkKPwkvMZ9gyhHdZqZONQvMceEaEGFGTVsIDQhUm6Ccn/nn9wl6+BRVcvF0wlYkKDPna/YHdjhSII0m7VdK3UWJO26+ubgc7Dk8fBhoSOxHi0T2JoeqOz/JnSfwkwKErLmsDcprorXtfanbm8hNWGlsAVbTqYIl6lI+ptsIbP+xpXtsZT2NhFaeCIeNgFab/WpRGNEwHM5JXVQYcmW+dLmfOnr6cpdqD76czbimCRXR66+upK8NNwpr24j5FQPgYO8iuyitIR 0PfBnmsb OEJWP4heUBhI2+kErent000RdmKFmslhHtiUEVhjCBKM/bOyU5kEERLuek/p39SyLk1erVh+TFrOhduFiFza4+YCc3PvW4aHy1DSNd/7zbAyIYifbwAOxk2ix5lXQFp21t9PmfOwFf3NpwEP05uLW7mudvkXFvzA7qVxSqTDqfLroczfQkxSEx95Cf6SYUVbI3u4GOhTcZoE/HcGbte02i4ZnhzmEPC3LxFk0Hywo9KtyMIruej8bD2FqIueGXJgySOMIK1RrabvIPKpHx9JY1uqDXGCwAfo9ZAg8yDz6qCFaivKdKAWIwMTOfPN4FZUUtNMXm34kwyQ9MzlTSUyVUfOsZgMIlZ9+jOSZZg7WglDGmFSD0HvsE6cgO/tRbSpyK4kihXPT98cmPbfgMpeatpHHrPOwOTWmMOC5 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: On Wed, Mar 20, 2024 at 2:51=E2=80=AFAM Johannes Weiner wrote: > > On Wed, Mar 20, 2024 at 02:08:22AM +0000, Yosry Ahmed wrote: > > Currently, the number of protected zswap entries corresponding to an > > lruvec are incremented every time we swapin a page. > > Correct. This is the primary signal that the shrinker is being too > aggressive in moving entries to disk and should slow down...? Yup. Currently, there are two scenarios in which we increase zswap protection area: 1. zswap lru movement - for instance, if a page for some reasons is rotated in the LRU. When this happens, we increment the protection size, so that the page at the tail end of the protected area does not lose its protection because of (potentially) spurious LRU churnings. 2. swapin - when this happens, it is a signal that the shrinker is being too... enthusiastic in its reclaiming action. We should be more conservative, hence the increase in protection. I think there's some confusion around this, because we use the same-ish mechanism for two different events. Maybe I should have put yet another fat comment at the callsites of zswap_folio_swapin() too :) > > > This happens regardless of whether or not the page originated in > > zswap. Hence, swapins from disk will lead to increasing protection > > on potentially stale zswap entries. Furthermore, the increased Hmmm my original thinking was that, had we protected the swapped-in page back when it was still in zswap, we would have prevented this IO. And since the pages in zswap are (at least conceptually) "warmer" than the swapped in page, it is appropriate to increase the zswap protection. In fact, I was toying with the idea to max out the protection on swap-in to temporarily cease all zswap shrinking, but that is perhaps overkill :) > > shrinking protection can lead to more pages skipping zswap and going I think this can only happen when the protection is so strong that the zswap pool is full, right? In practice I have never seen this happen though. Did you observe it? We have a fairly aggressive lru-size-based protection decaying as well, so that should not happen... Also technically the protection only applies to the dynamic shrinker - the capacity-driven shrinking is not affected (although it's not very effective - perhaps we can rework this?) > > to disk, eventually leading to even more swapins from disk and > > starting a vicious circle. > > How does shrinker protection affect zswap stores? > > On the contrary, I would expect this patch to create a runaway > shrinker. The more aggressively it moves entries out to disk, the > lower the rate of zswap loads, the more aggressively it moves more > entries out to disk. > > > Instead, only increase the protection when pages are loaded from zswap. > > This also has a nice side effect of removing zswap_folio_swapin() and > > replacing it with a static helper that is only called from zswap_load()= . > > > > No problems were observed in practice, this was found through code > > inspection. > > This is missing test results :) Yeah it'd be nice to see benchmark numbers :) I mean all this protection is heuristics anyway, so maybe I'm just being overly conservative. But only numbers can show this.