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 1F350C54E58 for ; Wed, 20 Mar 2024 19:28:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 983646B0093; Wed, 20 Mar 2024 15:28:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9336C6B0095; Wed, 20 Mar 2024 15:28:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FAC96B0096; Wed, 20 Mar 2024 15:28: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 6FF636B0093 for ; Wed, 20 Mar 2024 15:28:35 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 18D91402DC for ; Wed, 20 Mar 2024 19:28:35 +0000 (UTC) X-FDA: 81918404190.12.0DF6CEE Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf08.hostedemail.com (Postfix) with ESMTP id 2F10D160016 for ; Wed, 20 Mar 2024 19:28:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y9A0UP4v; spf=pass (imf08.hostedemail.com: domain of 34Dj7ZQoKCHUrhlkrTafXWZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=34Dj7ZQoKCHUrhlkrTafXWZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--yosryahmed.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710962913; a=rsa-sha256; cv=none; b=N1rUGSQj7V1isY0RMh2ejlrgeZG1EZC/tg191zwRq33N97suTE6he+/jdPyhYObPooD7xa qkX/T5x7IgDsQZXZ5phe0Hl1N4ep2mIZtrNRHSh1LDGV9KhAMKCc8Ac2vptlTSJoV6LDTJ Mcm+dsivfvm3Tftl+cSwAgT/hEu/B7I= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y9A0UP4v; spf=pass (imf08.hostedemail.com: domain of 34Dj7ZQoKCHUrhlkrTafXWZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=34Dj7ZQoKCHUrhlkrTafXWZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--yosryahmed.bounces.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=1710962913; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=h4SyzynV5kX7MGboSnnV/iVwc1cNoxGH6Rcm33p1x8Q=; b=52cmRdP8DaAju2dxL1NHPCmMI828JZAxborOhUW4B9lzr120xv9YFYJBv+ct8JyJ0DaDj7 8oWdf8kNfMM+UABthiD2FG7WFzLE8bAkUpT9U4zcOIUxo47RBGibhKZgwrGFTJo1PaSCjJ tqPtIMKuKc3qOstzIXlH8BKSzJaA6S8= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-60cd62fa20fso3022547b3.3 for ; Wed, 20 Mar 2024 12:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710962912; x=1711567712; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=h4SyzynV5kX7MGboSnnV/iVwc1cNoxGH6Rcm33p1x8Q=; b=Y9A0UP4vqgTrEairnX35Hor6xxBZoeQJL7qcql3t7oYDuES3LHqYTHQMeVeFTcc0Da GtSpS+XYJb8aZNL8248vP5dRCCLHlA3jbNzu9fB1ylmKtJ9fkd4NtNAxSgjSMzDTznN/ BPVtbrkWqwfNLh9fLTRgFl6Vr7hI2fLneGdn9wl67Bk7gQwtmmNgoGyqDGm+QVOwJeIn dbi2fe5c+0JK0F29lKXTPZL4b1cJzZCx5V6cSdqthY29lYFEPi8cTnCvFGA6op9fG9+p h7lN8oR7bzt/nHWOLZGpuE4cHlrnMKAn9aVt3sCmJWYg3dYBx21uni8r4hJW6D5uGBks h4vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710962912; x=1711567712; h=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=h4SyzynV5kX7MGboSnnV/iVwc1cNoxGH6Rcm33p1x8Q=; b=hwQ2/miXsJ+FlBahFkXSQf+cQRvEXlAB/7TLtdY/jCWNO+pthgVoWNtEhVt0dXVccP w8oaVc4paJcFpUVrFmGPfnzqe1XLyI8AsgRssHvYJVAZZoGZ6v5yqOda/fzupkMdNjvN 6p1wPcxIo7lP2wa0WjmerzeAYzdEILWWjFXchcpg9xd6b3I9DSqiPoLai8x4Mg0IiE0g 8fkAEc7OQ3k6DWUDnNkr/HVZbsgg+lsYiZRsDLFEyq1Y0CkxXSb0T205Xf+yYZhnVkw9 slv6uYpuBDHO6xs790Y62wMn6NvfqyUnKU77DJOOUkfqqkk/UvVHzHQKx8PjqgnjY6V/ wOLQ== X-Forwarded-Encrypted: i=1; AJvYcCWIWlI8VG1Lg/qipL22yrQCZfs2raOoU5XlvysMlHiy/yxRdCWBL+Mic+6V3IBdzR+IG3iY5Tc7i8WMEszEG9yA4LM= X-Gm-Message-State: AOJu0YxbwvYr1QyEQM3VSXednf2NmrIZvKTrnwcRXBluIJItqOOTB9YP q9KN1EAH3KBlIidNDpTXOrAWwH0Zvh5nA+JTHUEJIfZp6nT+LZMQ9m2Ie6u/4kaf6Nis4f3Fvlm DXPhRjF6tfqspEfw5SQ== X-Google-Smtp-Source: AGHT+IH3a2dQUxC4TJSM4dA/PWt+9z6duiRiapgfOcxtEUugqqSLV6X19kmuyZEz4bKbMgETq97MM2uua0qVf8fu X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:200b:b0:dc8:27e6:cde1 with SMTP id dh11-20020a056902200b00b00dc827e6cde1mr1029333ybb.5.1710962912296; Wed, 20 Mar 2024 12:28:32 -0700 (PDT) Date: Wed, 20 Mar 2024 19:28:30 +0000 In-Reply-To: <20240320095053.GA294822@cmpxchg.org> 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: Johannes Weiner Cc: Andrew Morton , Nhat Pham , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2F10D160016 X-Stat-Signature: yeyrei7kstz3fq7g31ypjf71rt4bxf68 X-Rspam-User: X-HE-Tag: 1710962913-261642 X-HE-Meta: U2FsdGVkX19910GQNfQ4d0dHSYItlCRBSJfguo7vynL3z2tzoRMruo7nwgZROb4tb54srlTVcVn0/h5rgnpMM6cSsI6RTFnTzmrG9qiSI/a0cxIi80CeTUSU+KMwVWDS8J+IZiN4Ivpj0YeKBoXuJzkh5cprEoH9ZtQcqrAe3MV4R5YfuzCuvMSQFSZezCdQVucCNGVSCGGO5E2UJWmS5/6vfP9HtXBMHqvVP5B1sUWIlK/Znfxy9R5G5p0da47xd8WdEs/JC6f+3TPrG+NJ5pd54uRK746eaoLoLTT9I/iy6WQkFWacZIgtZZPJAuM21vdBQBsGF0lOlWHhCfKtjxsVM5pDfbdRUhoAdnzpCuvS6LZiCK7Kbp00FDYrnOBhwWQbS+Wod0L7UsKlH7P6UvQlk41vkCKcn++zFyqqUULfFe79LqdotW3fjfN3l7tTQB6aHBWHnlCsbWWO7/oDVAVQAwbh3UMKlVpIV8BzntbE/QU92AHGgcOsL8cjG0dVbvpeUL1FB07OaD+1PCmHMHXAoP25tVUL+ljwUhGCs/sOne4DCGUwg9l/bA92MGnEYCRtMs17oyEqE1HmP6uZKLXpxLhZ9d2z8+WgSKn5xhkR55kiWZuWncjyDsGpaGGMYJQYqiE5kY0DH2NsNO4+sAc/+K0bKCK4XYRjARBaxb8Rzj99Bi2M+2WDuValjNJLenxy9X5d7PcE6YdpXhzQYkF45jfTwL0JhbgsaTq8Ti4Sn/6QdRUx/VFPVfIN9ZZd37abU7MW/1FYTHLAy+ayAA5QrJCI17beGq8tfFeWzB1H90XKP+VVQP2mSgLgrQhXz5DbTe2LE0yMZwhoHtQzX1t5XZ9iAKuD/xg+3eQCujd6GNY/nciWJ0Gh6FDVxCgzCpCwwo/ftJK8PfcBshvofQYxwHj1YKASb2l3YuBAebrTgxkmqmWlCxcxyxx41TbaQvqnT/8Ho2OZgMUoC9W 9Qm6qzU0 HxYgrczg0WtzyuDUUIbR8d2wbnma/eXLmTo8fyiwgtnpXw95fHS/G+qyRWSDHEfbnXPT7Jgm8B0D0MFDvj6k+RVymcDgVxOLYAqMhPGj/61tV6tdmvil0nK/IYYWPSE+owQwk5tEXww01Nd0XEqwmdlv44K0ZcZhe9JTQFqB2dns/rUxfJC39l+w/OAwCA8lE/u7VoHH0IudG8BmOfY5sjMLr0Wg8QNNwrnOn8gkxdCh8FmvGuoaNKTB+EOVhD623MQIB86GMnwPjLmrhjRmeLnJWax7iJhuTYXLmNjwjhYnD+dRiQ5kVmaKfdeApU/BQP9Om4chSJ+IBX714qIeqQYctJR4EGn3m7u8TILCXOwH24rbwPWCgcm0BcqIfcaT7qLfCH4PgB1kxWEI5MywcaDnEx5ALwA3joMhzzQk+kN6ER6anZ2AiRC11dZpnetMxYo5eLL3ZscXlF3M5hwgnHXoDmc1NfngGXBq9eh0hpvU+HrSOzyCO/oon2S1W/we5c0QQrWlTNR7r7ulP8upMMk1eONENr+aVtudGOECsahLo+mfW/rtZ6xRLnkThypWLBoPjhY8EoyP52ckSzfDpu/DBqe693MieMrjeIxDN1+fGY24= X-Bogosity: Ham, tests=bogofilter, spamicity=0.092859, 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 05:50:53AM -0400, 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...? Right, I think that's where I was confused. See below :) > > > 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 > > shrinking protection can lead to more pages skipping zswap and going > > 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. I think I found the source of my confusion. As you described, the intention of the protection is to detect that we are doing writeback more aggressively than we should. This is indicated by swapins (especially those from disk). However, this assumes that pages swapped in from disk had gone there by shrinking/writeback. What I was focused on was pages that end up on disk because of the zswap limit. In this case, a disk swapin is actually a sign that we swapped hot pages to disk instead of putting them in zswap, which probably indicates that we should shrink zswap more aggressively to make room for these pages. I guess the general assumption is that with the shrinker at play, pages skipping zswap due to the limit becomes the unlikely scenario -- which makes sense. However, pages that end up on disk because they skipped zswap should have a higher likelihood of being swapped in, because they are hotter by definition. Ideally, we would be able to tell during swapin if this page was sent to disk due to writeback or skipping zswap and increase or decrease protection accordingly -- but this isn't the case. So perhaps the answer is to decrease the protection when pages skip zswap instead? Or is this not necessary because we kick off a background shrinker anyway? IIUC the latter will stop once we reach the acceptance threshold, but it might be a good idea to increase shrinking beyond that under memory pressure. Also, in an ideal world I guess it would be better to distinguish swapins from disk vs. zswap? Swapins from disk should lead to a bigger increase in protection IIUC (assuming they happened due to writeback). Sorry if my analysis is still off, I am still familiarizing myself with the shrinker heuristics :) > > > 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 :) I intentionally wanted to send out the patch first to get some feedback, knowing that I probably missed something. In retrospect, this should have been an RFC patch. Patch 2 should be irrelevant tho, I only bundled them because they touch the same area.