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 D1D8DC6FD1F for ; Wed, 20 Mar 2024 19:32:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51D536B0092; Wed, 20 Mar 2024 15:32:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CA856B0095; Wed, 20 Mar 2024 15:32:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 392A96B0096; Wed, 20 Mar 2024 15:32:38 -0400 (EDT) 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 29ECD6B0092 for ; Wed, 20 Mar 2024 15:32:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 04D12A1A82 for ; Wed, 20 Mar 2024 19:32:37 +0000 (UTC) X-FDA: 81918414396.01.8AE339A Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf30.hostedemail.com (Postfix) with ESMTP id 25C0B80014 for ; Wed, 20 Mar 2024 19:32:35 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dzfaBWbh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of 30zn7ZQoKCGogWaZgIPUMLOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=30zn7ZQoKCGogWaZgIPUMLOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710963156; 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=zU6HfdEt0n6J7E0KRf9O2/4bM68psIyCtb53kHS3Ps4=; b=0bheNbIFX3kRHHM/Wyi9+V1QTDvpMzx1S3YhDU+Ts0P9ojA6j8BP8qPR/gd5i4VRX9Kn7q 4FkgS6IDzKzf6/pnHvE5WPC3L8gKhdocfy4KmZc9OHrn0q3LmzqGU+OqAOlhhUHV5biRa6 bPcOuRntsL8aQXcovtpRTE+fBJzzZWs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dzfaBWbh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of 30zn7ZQoKCGogWaZgIPUMLOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=30zn7ZQoKCGogWaZgIPUMLOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710963156; a=rsa-sha256; cv=none; b=hklONrMRh0IpRgP5O1y+vHpZCU3qt/RkORcvwYRIAhyBwOmiSN0LPWSIfZZLuICcBjHKvX XMBR5AivusiYqAXXwluSlU7by3+X5w3D+EUSzkR0Ce58U6wdV9b4c4r7/whta5E7pW5aui mPaINfdOVQvyC1Jna6RBX3CcL8L1ksg= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-60a0151f194so2646547b3.1 for ; Wed, 20 Mar 2024 12:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710963155; x=1711567955; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=zU6HfdEt0n6J7E0KRf9O2/4bM68psIyCtb53kHS3Ps4=; b=dzfaBWbhcXxhlmxfEDCxTcU34fMEbmCYNjafPaDyihhBQoLnySqIfCw0QFxN/Z9Kf5 G+LuMyV0K5semMoCMWC623kiAmcYGVxOmNY752OlFtE66YmSr9GvuQzK3XwvGekz3VX9 i+/t5cCdPwI25saV23f4hLVnx/oly2hA30V6w95je4c8oCxlH2LZHGCOGJ67tyD9l0os LyZDGTWNhAeYNjeu/TglSzem5aj4FeYNZCr7AD0NQ3VWRizvn39kUP+X6j8WxScsu/ie o0XX6UwYBQiHuDMkDdJRxKNo1gBFUpi/Bc3MNRznJp72UH+y7V5GwKhklrLmA1HunrUB NTVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710963155; x=1711567955; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=zU6HfdEt0n6J7E0KRf9O2/4bM68psIyCtb53kHS3Ps4=; b=m984eE3T7WGRlGoYPAWTavs/vLZCOkqphuuGdCtfQiiQQMcLljKEnaYmxn9EJKWRwy nscNbDBW/TEheKmi8hCb2MHZ5k5iEgisMolyVKuJu2vvtlXqdlJJJ3aL8ppaVOneg4T5 HICdVJnHf7aIutTfcLxjUgCCHfMnBdWzKuRFzNsFrYrDwmgkUjudYmECxtmQm6jnAibN vtGOAu3ZVYYgNuwQYRUuUGEmlEOE9910GVNE5mxTY0vVghK+DxQiIXLg2d6Dkx6cqV8z WbhXwp1uN2cmhCuRT0u8n98ZmgeIIhJF2HOcnnqE+y3tJhD78jKUWByCMpDgC8yVPMby Vg0w== X-Forwarded-Encrypted: i=1; AJvYcCWoQlMD8bbfygvS0fyqp6iZv0CT0cYUaB92nPcqxtinHrv2gSzJz7Bp7pE/ae4+zBN6/uiiFl9S7kjkaeIkMlBbNZk= X-Gm-Message-State: AOJu0YxFGqxXwC75w/Q9Iy00t9AoEWBgLr59Yidrrjgy0r1xv90+GjmM TU8mlQIRj/a1x/e4hUajFREYuIh+eO2EPsBiru18KaEjyygoHDVfT+6btoB/QyeQ/K0lgKYQ7c1 y5sfVekXW8bxlHkmt1A== X-Google-Smtp-Source: AGHT+IHe0JLeXDle0EC2yBifL9imMy9PxVYfZirzbgToNKkjp+aG6E6OD+MSxTTdsJT8QB/n17787kHK9ZX0Fh6o X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a81:a0c1:0:b0:609:f088:cf9c with SMTP id x184-20020a81a0c1000000b00609f088cf9cmr4267979ywg.1.1710963155237; Wed, 20 Mar 2024 12:32:35 -0700 (PDT) Date: Wed, 20 Mar 2024 19:32:33 +0000 In-Reply-To: Mime-Version: 1.0 References: <20240320020823.337644-1-yosryahmed@google.com> <20240320095053.GA294822@cmpxchg.org> Message-ID: Subject: Re: [PATCH 1/2] mm: zswap: increase shrinking protection for zswap swapins only From: Yosry Ahmed To: Nhat Pham Cc: Johannes Weiner , 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-Server: rspam09 X-Rspamd-Queue-Id: 25C0B80014 X-Stat-Signature: w1axhe3bt4a8rjia96ri8msfbdhsppmy X-Rspam-User: X-HE-Tag: 1710963155-433108 X-HE-Meta: U2FsdGVkX1+k6b43bF+i9QAr0Ks1ud7tvB8KRHMy6oWgXDRB7Ibox12IggPGD1nmcvnmC+02CDMh8cOsbMB2OzIfFvBfTqtAsYdSpkzGr2h9Fh6xGlchckAElYEW0Hr1Rz9k1N/pZ0Wfa8qRaYcpPIXF8q59kC1FcIGNWhDXD1KXi8tl0VmW80Vfhq70H9xqSj2+6d/3EQPe6H/3EJ2uzBb8YGXI18tRRBSrKDjHjYhhJWecUFcX62NxssgQZlHlsB0/76qpVCB8bHfKQeumaA8VNAn6kUhS/n8lvC3WVgQ+sRx/BQj7IWMSneirP/n7WnSarGmgyQmDcKb/Xzrt/cj8qn5+XCDS9z4kbO0gsZqW33d/UBlCyWf0bgWWrLrpDFO4Xj2oJgfTId/eaMSco2/whswQOi+c4sbKFsS08ufcAsLOHkoyNEkrVEwjl5bOGfuBTMWh3qQJDGEeu40RTd1uZrX9rFlrgUJKjqmOvLRHl5j7VX0Vl+o/7IAqfC7L9aENtIMzNsp9UErOW7wT3vmoTBRDd1pocEZ2/dLU+eLUq1jmiASCfaqd4iHiHQwDOSjtSs65tWfhGqW/5u2dFj4X1OqUSwoRAIwORRmqewM2d8g9LdlZl6jM/6QimOlV7KNkG1lMQ8PeRCRqLl80DvfvBwi6iISlvCkyLedMsQUkvqD04CnaAxoTY5nPmW118wkbehTd7xnY75hyl2RYxRdaOTTnaHNS4FdZMwOfucTzjEQXrmzWVyx5nJWGnadZzBxJzLfINdSOlh5eCTQCYdkNTvDq2rxxgE1KX8pLjnd4P9O3baMcsj8CqneS+FC0FvZh55VllZ/ZjQ+Xs8pXGP3O4H9JsoPCcr492r3EQjLyWh7vcDi7xWk8ee357g7hSE7tKfChgO1nMyTEgjfjIhtRuqRYigDbLqdQHluSxhT/OaSkMH1r1T56rmhomy007PDYCSbhWRCiJmJsqGX cE4tk/80 5N8I4DKy2gdKMZmERDkareJf3hI3YZvkDQ/BF7XDZXdq9iLnAhVQKgAu1GS/F8lus2FTcM25ZXnZrRThL8VRXSvWY5jE1K5QJraP1NZDRRMURXqBihnZjP2NrUqTwyTrOkPzrml19VPyqingowRBusYW75dw35jiF0iCYJY2Ltk5uS74PQQW+1c42tmLtahRYZfKSNLARictoZ8nb+/fvh/G00GOHDyGeAcbnM6/p/22JIQXR/kvoJR8+/mjWdavvND57zFjIBoWrU309hUdAtJG77V8LJWQINNTxvtBhAQFfEtNpRj6AXtQRRmuTDa6jvA83qmFjLt4n7/udSH1gLb12W1qSXz3PXRCA2wiEy0sXMS5PC9eXxfch/zPHug7FWV00HE4isrR/v3jBlwDJ9ZCbkjGFL8XX+2wG+HbnSt97Z/S0HglvXo+DC9CFE/E2eR0oTE0QpwT74SI4y7lFtz/9TeGEZGfGZB0FMAnbmn1W4ZMFFoTwGVnaqX/+UciiYqV3ZDPIPvRoCD9x2Ik8/+xiUlPMLzg5VR0pOa7q5Nrz7N/CXDgGx8S9LRGFt/nbSOJbbTGnB9r2oSmbhRP4XkDU1QvNkle8UHt/n+SAY/69K2j2CK+7abpmra4kPkGzCctGi6OJZBIu4lAfyfL8sKJpqc8zeBScyXkxdBqZRTt9C9M= X-Bogosity: Ham, tests=bogofilter, spamicity=0.105893, 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 07:48:13AM -0700, Nhat Pham wrote: > 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...? >=20 > Yup. Currently, there are two scenarios in which we increase zswap > protection area: >=20 > 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. I don't think we update the protected area during rotations anymore, only when a new entry is added to the LRU (with potential decay). > 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. >=20 > 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 > :) I think it makes sense. The confusion was mostly around the interpretation of finding a page on disk. I was focused on pages that skip zswap, but the main intention was for pages that were written back, as I explained in my response to Johannes. >=20 > > > > > 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 >=20 > 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. >=20 > 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 :) This would be problematic for pages that skip zswap IIUC, we'd want more shrinking in this case. >=20 > > > shrinking protection can lead to more pages skipping zswap and going >=20 > I think this can only happen when the protection is so strong that the > zswap pool is full, right? Yeah that's what I had in mind.=20 >=20 > 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... No this was all code inspection as I mentioned :) >=20 > 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?) That logic is flawed anyway imo due to the acceptance threshold. We should really get rid of that as we discussed before.