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 B6DF5C3DA7F for ; Sat, 3 Aug 2024 03:22:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 290226B007B; Fri, 2 Aug 2024 23:22:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23ED86B0083; Fri, 2 Aug 2024 23:22:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 106856B0085; Fri, 2 Aug 2024 23:22:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E6B2E6B007B for ; Fri, 2 Aug 2024 23:22:46 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 84CCA809B5 for ; Sat, 3 Aug 2024 03:22:46 +0000 (UTC) X-FDA: 82409487132.03.F1793CA Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf15.hostedemail.com (Postfix) with ESMTP id A6C34A0009 for ; Sat, 3 Aug 2024 03:22:44 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xGJAO5JB; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722655307; 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=2V/06i2RmUvlO+zSr7S7F/ykckUyzAhmZ5TEusO50W4=; b=G/IgrEUn6djcYGQ7IGnSxV5sop8GzQAScVXzJXJ0SlHcn6t1vnH8QbOFDn466JcgnEvHjW NtSX4G1KEuKaPLZ3SqnnHh32n1Cc7bimYZRZl/uTHV8WRQZoasXK8zVscxEFVCyxcMEpqv Od6dmz2IXPKAqCSTdWNnVGCFdyU1YUY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722655307; a=rsa-sha256; cv=none; b=73auBkE9CB61+GsW5+oS1e/KCaWOEXiiJdMfw4VDa5stvt3hDdR1VxbPoEjWIA91PMwnne qW7uG+e1Js92yVCXEo0O7EMHeJXUvidsERxqJ0CxRcow27pf0sK1jSUNl/kc0zF5mrPYG3 FcpdErbzAE/fKQPyPxZeM8MF6ioseo4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xGJAO5JB; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5af6a1afa7bso10014399a12.1 for ; Fri, 02 Aug 2024 20:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722655363; x=1723260163; 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=2V/06i2RmUvlO+zSr7S7F/ykckUyzAhmZ5TEusO50W4=; b=xGJAO5JBPfgP9whlJXHF71h6kaKJKGTIOLljdwyP1raRIyBI7t1qsFCQp1jMUVViJ6 xpr4gWa4wL0V8nASWUCweW92KtXfYWv85CDqm1DZbB7X8aWzsfvexAqXPlqx94ZGOEX/ BT1VYt+wbakM18hiH5s53ekvPNQhAyfLaEV2E1oVUSFV4kAMsjf+/EKGl1jeMZWYYG8B cVMO4ezAd0QC+HX3/yJng3FsaB/fH0ioceW6m/v0qQFiRSoZYZ4XSY7ihkYg3dVTUA9P ANpsUmEMdeFh7qRSlpMiJp2lnJ9hWtkC28FZVrt71sH01OLfPBaSycVAT9FOSS0yXnKk gmTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722655363; x=1723260163; 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=2V/06i2RmUvlO+zSr7S7F/ykckUyzAhmZ5TEusO50W4=; b=wPpQw8jkwSfdFWc4W9k3/+8uRlcOou7WWS5yW7kzTLCiaaxH2JEa99QsMEVa0sY6Oq sXKxHlllJZrnvEwyW5ph/rVZpbGkH32nXdo0aU6GnA+vmkvlofOc2DXnlcvZJRxazj4l V4m3D5LC4IDXTD7eteweQfwCkmc+9oEare6Cm14rKlvpYcMzifmA1rJsWIPwpVTjNyk5 5D72JpYK5fX1kbpmnvb4+60o8fzbNnwXvHqpIO/KqwqesnU69xdFyXykfWecfx+pdWpo gKWJCVpxB6ChrXSZTAUv1hMUjKGAOjJ+DyUdtlArXChAwQ4mLQCLDbSVkAiqHMh3MsRe /olQ== X-Forwarded-Encrypted: i=1; AJvYcCV69sky7GQSQhn3ud0c0ktp9vG3956TLhHX6fAhb0icAllP9vmO+AQuseV+AGvaaxcDnNMeOmYeuk9UAleTYYHY+mE= X-Gm-Message-State: AOJu0YzAdr5npwyC0R2Z40brLDOmrJldY/vvrU5anRD0u7P4uI8BTNPn dBB34vh+nOeXPT1mqJVdHw+UdlvQsoMwsket4DNi25jdnAg0yNzpg+NKJvv+vPh4+5rHb1bjxaj 7PuS8dWy7STg7fTnXdqNsnOLamoIScpI5JmRt X-Google-Smtp-Source: AGHT+IF3WLjswsizJerD/J9q/Bv0f3kbx9LG+/VDuY1yX8RvUOgkK0vBNoFLb3ai+VonbQI56jpLpl2gxnVsTpyBrHk= X-Received: by 2002:a17:907:1ca2:b0:a7a:bd5a:1eb7 with SMTP id a640c23a62f3a-a7dc5105635mr380652466b.59.1722655362339; Fri, 02 Aug 2024 20:22:42 -0700 (PDT) MIME-Version: 1.0 References: <20240730222707.2324536-1-nphamcs@gmail.com> <20240730222707.2324536-3-nphamcs@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 2 Aug 2024 20:22:04 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] zswap: increment swapin count for non-pivot swapped in pages To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, flintglass@gmail.com, chengming.zhou@linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A6C34A0009 X-Stat-Signature: mbqu8injekn9483sb554ebjra5jnuznj X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722655364-703281 X-HE-Meta: U2FsdGVkX1++dq7ZYaVsp5n4lw9cX1ZGUsdtiMxr5g66pkXlUIT7CPywB+pJlfmk9fbcstiShZxiaPJ+hB4h4ONs/1g+4Xup0z+Tdrk4PtgrL3ORHpWt7e/46Q9BWrUbe+ipZ4gAnKdSEFl7Nig9v+lxIPqMeQa5yvodadYmXWN/kM69mNBSvfRUFydVtRMPoTqhJvLyqhKpLA1L1R087VwtzxZ/qN56BOTeyvOqMDyTqCWhBp21hNuk8Ga+BsKpbhInt/uAlJHchBBqY1kY1e38Hf0TsRmJZUQR5LCMRgeNEyxC6WjxhdPwqykVFYk7fCPJn0SDg2eCNRW80fqeBiQUZXe24/Mc6aEcDYW+Nfc+Z8N25rPKIgpG3iNxLQZcNbUS4whN2+ubVG3sTkHWe3BPP7wlX3vKJYsQzcu1XOgKO5pblzVLHDco+1FbplQ43u01SH3qZ7cbp0M1oT62mYfkCe8ScPuQ7Ec25Y64MG4bd+6XRWPGkwqqF8p2mib3yyv0ee29o9loRK5lbqlsdk5Dhet+wB+JDEosCmv8BvoQ58IyTdgAWj8VzaYR58Sx1q1NsNcarG3OfJukCwftFcH5rWTcWmh52CSuB2ZsFXw84DJP7D4wn44r14WfEgPKh/ByOneQzebjiuGhsauWIV9PhlHRoFrqq9HgRCsfzPq+axkxYz5NJurcLcoGHa3slh9mP9ah72aEmG02nJNzGIp5Yqoi7MoSyG32dc/tPHQKesXsLx1kOgRX1O5FaZhS2RVeEMeC8Kp4lz+r94NBk+zADhaoXo70DpGHJE8D+fiZZb0hb6bBhs3Y2YcPHDbyryTCcdTY3ujBR41ZHfbz8uLcJAPFE52+Biaxujpn2JFpAGObOLUUIC0BGs9IIQUzJXuYQLOiqSFeCCN4PMmCyqYh1zF5fUAc1id0xsS0+3umimGLn1A5RKWUR6elxDuh1Bju8LTa4MEZu//wijs QBgE3qfC pc+WxMkarrhqVDOBVOubIovmnwqQtIS+C+HZpZa+ThTVU2EKpq/uJThmGJgfSrpGCOnhSyn6CD2er/+O4Xq81ciBlbzIEmXO1z0dzvcKc590zdwcv+qwhFxyRo+rDx9YV5hzu59tB52rrvk8W3B93cLwDA827NmcQWsQS+MOlARZG6mtGM3F/P2Wy9cl/jSfISei7qfhGewICaCfmQrP4sMQ4yA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001037, 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 Fri, Aug 2, 2024 at 4:46=E2=80=AFPM Nhat Pham wrote: > > On Thu, Aug 1, 2024 at 1:02=E2=80=AFPM Yosry Ahmed wrote: > > > > > > Hmm, but there is a chance that these pages are not actually needed, > > in which case we will unnecessarily increase the zswap protection. > > Does the readahead window self-correct if the pages were not used? > > Hmm yeah it's kinda hard to predict if a swapped in page is strictly > necessary in this context. We don't have this information at the time > of the read. > > That said, I think erring on the side of safety is OK here - my > understanding that readahead, while predictive in nature, only gets > progressively more aggressive if we get signals that it's helpful (i.e > the memory access patterns display sequential behavior). If the readahead logic is expected to adapt in these situations (and I think it is), then I think we are fine. Perhaps we should just leave a comment that we may increase the protection more than we should for those readahead cases. > > I think we also accept this slight inaccuracy (i.e for pages in the > readahead window that might not necessarily be needed) the in > workingset refault handling behavior. Could you fact check me, > Johannes? > > > > > > > are also incrementing when the pages are read from the zswap pool, wh= ich > > > is inaccurate. > > > > I feel like this is the more important part. It should be the focus of > > the commit log with more details (i.e. why is it wrong to increment > > the zswap protection in this case). > > Yeah this is pretty important too :) Maybe I should make it clearer in > the patch commit. > > > > > Do we need a Fixes and cc:stable for this one? Maybe it can be moved > > first to make backports easy. > > Hmm. > > *Technically*, this is broken in older versions of the shrinker as > well, but it's more of an optimization than a bug that can crash the > kernel, so I don't know if it qualifies for a Fixes tag? > > Another factor is, under the old scheme, this does not move the needle > much - at least in my benchmarks. This is because the decaying > behavior is so aggressive that incrementing the counter in a couple > places does not matter, when it will be rapidly divided by half later. > This fix only shows clear improvements when applied on top of the new > second chance scheme. > > I don't have a strong opinion here, but it doesn't seem worth it to > backport IMHO :) I thought it's a simple change worth backporting, but if it doesn't move the needle without the second chance algorithm then it's probably not worth it. I would still add the "Fixes" tag because technically the logic is wrong without this patch, it increases the zswap protection when there swapins from zswap which doesn't make much sense.