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 65C95C3DA4A for ; Fri, 2 Aug 2024 23:46:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A8D26B007B; Fri, 2 Aug 2024 19:46:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 630636B0083; Fri, 2 Aug 2024 19:46:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A9726B0085; Fri, 2 Aug 2024 19:46:35 -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 2C2306B007B for ; Fri, 2 Aug 2024 19:46:35 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 92A731A0B7A for ; Fri, 2 Aug 2024 23:46:34 +0000 (UTC) X-FDA: 82408942308.16.D6BA235 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) by imf13.hostedemail.com (Postfix) with ESMTP id BF0B820010 for ; Fri, 2 Aug 2024 23:46:32 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nhwO0eRT; spf=pass (imf13.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722642334; 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=p0VO9AAFOYlOn1ibdSbRR29b7NvmxqsvTypHdjJuU74=; b=q26lXMVShz0+n0IqgFDYGxzvnzJtTS7YeusB6N62ZpOFttsDSM/0sxI/ppKsCRa+ho68v7 otgt7wLk1oyf1zXJLx5DIk657O4l0PcuxOg12x1F2SisK9qrooPRTlZ3ONmijYPl3WITaM OL7W6+a0ORQ99xdPXjIw2N8lvqSYcbw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722642334; a=rsa-sha256; cv=none; b=TIE/86BT/hwT+e5VLQe7LHPERGHpkwWQxheSGgs8wT4N1XuJsOWGKw1LP2SfNShg8e/7NG zaN2DcTkJ/BvL7xNpWeUOw7FEXxTzzf60Tdxrvz+Py06LDdOfyIybYoWL9tb7c2jB6+s3u XFEzjXTtG9bDPGpJcZJLIO4DbjU9LxQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nhwO0eRT; spf=pass (imf13.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6b7a36f26f3so32476956d6.1 for ; Fri, 02 Aug 2024 16:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722642392; x=1723247192; 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=p0VO9AAFOYlOn1ibdSbRR29b7NvmxqsvTypHdjJuU74=; b=nhwO0eRTm6+88/ObTEzVw+FuDdPzxMZ7cH1ys/vpc9B8ET4QBkhsSeG3/JG2MpuozK z/InB03dQAlUx4BDRwXhki4ywnxsujTjiAuoIgOCmrokgTjLRFnGK1RcNTluxDHHggg/ HWCMdFTC3JCtIxBlt+vx1lUMAWe5d20u3Z2+tqDizMYDGdGavgx2PUtpTjVxVcJvlSp8 GWZcCwF/LzK4FbsKHeuuFtH3gu988hf13aAwCysIxDcs2HO3kXMdK1TojZDrExFkIljd OcFaztt4ZaccdNXw+SO3dezB47vSexhWpeK7ISJJ6S+mSOA2V7Z9xiVQr2l6XNXqnBY5 6sSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722642392; x=1723247192; 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=p0VO9AAFOYlOn1ibdSbRR29b7NvmxqsvTypHdjJuU74=; b=R1elVIlaXrK6p7b/dFzVhkSGPqMiDC5bn7eM9oCQajE5Irmm9XTmd0CMh64PL3A2wv iFy2dlcap1frrlWE/X3mXwrx+3LmyQ5ziNT7/NZZKBxnrKmjdrp7trekDjW/aFqta1OU qPuOnWx4V2VrcRCo5I4XPjvg7aE1b8ZNfuRPEigfNL1cWZXrWm0qKEkagC+lB2z4l8Ai QX5IPiht06oSeCzJQoOrV/Pt3BHBDhpALqh41Z3PwGro0kWpzO1VR+5x755MFVM2lS9O aqQJqm03U99TLBpLOfVakGXHM59V/no6ajndpG474jjADipCV/DHqyMYNDdE/db/6aKp 7ZDw== X-Forwarded-Encrypted: i=1; AJvYcCVpu2uhPMif4GoS8ccPx+61hrPZhbOzAiIIDPbla0KW0QyEjby6POIbO22l1SrMbdOAqRoOLR180uGxnDwhgdtVC1I= X-Gm-Message-State: AOJu0Yy2+TQ1mzaDiQCHmeMzGwLFPhJDzfh5dpHp1gYnLKo0hj+i9sAj zyycNMH4i/AzVdB6Ro5ZhFXdKxrkiYnN9SgPUr+fejaini2U7W4+w0sy6eHzbyFywRJd24g6sK7 Y7hYRF8/f/QI/AkEtnnBl4FDffuA= X-Google-Smtp-Source: AGHT+IFwMz3O8xmawpkf8NI21HuJZvxuz4Wja2a9+ySclVPYbM7KegxgC6/pV7sIOXHUT8helne+EdXuWok7C9+RK8M= X-Received: by 2002:a05:6214:418c:b0:6b5:82e1:f89e with SMTP id 6a1803df08f44-6bb986d510fmr99842366d6.9.1722642391786; Fri, 02 Aug 2024 16:46:31 -0700 (PDT) MIME-Version: 1.0 References: <20240730222707.2324536-1-nphamcs@gmail.com> <20240730222707.2324536-3-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Fri, 2 Aug 2024 16:46:21 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] zswap: increment swapin count for non-pivot swapped in pages To: Yosry Ahmed 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: BF0B820010 X-Stat-Signature: sqcdht1c15n5gk5s3z9nbsdf8aewnzar X-HE-Tag: 1722642392-211431 X-HE-Meta: U2FsdGVkX1+dAcVAbAW4GGWfWg70zt+djpEVATggj5Re9N5pEraxfIY9Op9nBfM0G+/T8obmAJ4anxX35yNxTJfNHMveHoE7R9cD433zPCUBKDMJAgeaWEL4gbSXDW38UVzGZJ0eZauNh1Sp6sx4oN7mMb3jydJcVIA5lln/xcdD0L1DJSpcPD2HnzL4uB5a5gwHXBRASeS9dlZTeKSkpJCRLtSagQuoQy4U77rR4+mY8qiduFNzEUIatE5EwOiG6klxUhq/NmxQFyw59b6qrIO+6PoATKtd10pB+D8wB+ATG5r7hrdwN+dNUkGAsP3mWB5vVLcR7Tqw6dMEu/3jXp4jOpVb9RdzqHmtKEz4CscWdovyTUPXc9km0lFV7EMdWHJSMwLKMrg7U6MoscIEpOqSRcepUini4fy3lxCELCzbnCvTtW63HzGgi8xpM+42Y33SHXMX4c59TWaYE2q18gJnAaFiePDRXprQi+7vkKzsMiWdz7cVFTdSG42FknnhxcWSXu7/7DH7kHrG34H/6OMUtcbLXbwioBHy5Y8YIhLU6/Fynri93bIcuq1ZDqL0+NFyMqJ+UuSlF35x6OinKCjR3s9/0MBCxVOaQl7a+boxkVI3dzMmAVtoHgUllnlkr6bB441EwTfv09/AGP34uxBPFpUKMPB+5WpmF6sU0wKxuVn6S7qFLx4e8zhUi9KjBRQi26cSWag8S5wn/FqRwfXYIAfwR6eyYvsoYnLCIt1zgFqaVY75hsPuZ/nxzc1CX9RDwt6TBbuKSd7eWc6jLiybbxqFj24n+OYnvENnBvHLEWITsuIp4CL/ZJz+8h3/LuYZVUiLaXozbzZTr9Jyzn8aqnGAPmXuZi7XExDO+9Ggq5LrHPQ2f0vAuU506y8QI3wS3nH+LQDv3R9qh1YqyZZhLEPi9DieFeUC+8drKmDiIRUbJWnIoeg3plqjg494TMtU6lqp0l4Z6A1ibz1 FmUaB+k7 49vUL5usbJ3fXuCkdeSiUf5G4Z1eloPFh4hh3IYPayZjpJZ/MiPWfcXgl32jJqUxWvk7ZpTOefjfGpdyiuynMPEf2K1QRiUo/doXQYIP7IEFT7XPTjDN5lgB8G5eaSK0R0UtRkB72jlSf6TakoNLjFhgsQh/HP4OqqqrsC1bMUWcbkt89yftYglkkjdovkKN4t3fu0Ut461wiYYqTYmX/vlK/UqeYPLsYf+s56YvJJZNeXxG/Ry+l+NBFrvtg8CuTHdea1vTNR8yQJnXpfImRJzbS7yHhj1Ku9h3kq3xQ/Eag1tQcSl22N8ahoIwNoGxrlJOC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000371, 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 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). 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, whic= h > > 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 :)