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 EF9DDC3DA61 for ; Tue, 30 Jul 2024 06:23:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54E416B0085; Tue, 30 Jul 2024 02:23:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FE2F6B0088; Tue, 30 Jul 2024 02:23:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C5226B0089; Tue, 30 Jul 2024 02:23:16 -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 1890E6B0085 for ; Tue, 30 Jul 2024 02:23:16 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8B626C0121 for ; Tue, 30 Jul 2024 06:23:15 +0000 (UTC) X-FDA: 82395426750.28.1DD25CC Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by imf01.hostedemail.com (Postfix) with ESMTP id B0B2740013 for ; Tue, 30 Jul 2024 06:23:13 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="neV0/cZ2"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.45 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722320553; a=rsa-sha256; cv=none; b=TjF9tblV2uq9kEhWyGxpfaUAZmIJhSWd2fbzyA1wln7QlnxT7xJ+1EMwXqMfqHXQ4b0H1z 62GYjYT2GY4g4uk5Xm9c5r/gjJlhp5QybSuYOV3tRKo6ABat4hOYDM/Q+mAfTF5ZQfbsSt Kpld7QretNK4SKLC6nfT3XfjPtXf9UI= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="neV0/cZ2"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.45 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=1722320553; 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=Fn1XpXCE3F2UiQm6K2YQyMZaD6wcHBWyJavcktEFMnw=; b=z384f/m5UA0OO025Ml3rh13SNlJAQAKxxbcLRiZT1IJx5IdzdSRnO9CVExFLjTHlptJHdK QRV4Nb+9LfVVsOQnYVjSHwBIxH5RVsni+RGKbW5wtxOYIyonmmcRJcCRVNJmO3vzS4an8b XIpN9NCpFig6y1e3i+rzS9mlNBQODJs= Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-6b7a3773a95so23261946d6.2 for ; Mon, 29 Jul 2024 23:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722320593; x=1722925393; 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=Fn1XpXCE3F2UiQm6K2YQyMZaD6wcHBWyJavcktEFMnw=; b=neV0/cZ2gHZgI1D0ZCgi7s3KCTIeKJyE0Oj88oZtFBZ0xPe9wfFghkZDt4TZiyl7Rh D9hYMVmV9udR7M59QYfoTHlGUaN039E/oqGGL9W3ig4Q8RGFe+8GTidDEzYO02zlDyb8 nc0ZL/WP76FexA0bUZvXEetnBEKBFKbSTuiFxo26DlpY81DVehlOFTLu/FL3Dhi1TL2s UZat4HsBicQWLh09OTwfMXbYQlRUBjBXniYhhVzYM/mNkm7IgB5OmllrWdh4UPUvO/yo YSt/7SHa9arGAgysClK81w1RTxJLDbj21+R5huFBgzscW5CLBHnPU1sLGp7D7d5wJY6x PYlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722320593; x=1722925393; 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=Fn1XpXCE3F2UiQm6K2YQyMZaD6wcHBWyJavcktEFMnw=; b=rM+JkKLVApGBfmF3o/mI89yMOH6QIRpYePjUC+wl8Ktbx9wZBoej53lAEHTRdoiOAE F8rePDj7pBSaTpmfDa9vncoOIOc7eVGwt6J+Eq6ke26Fx5lyG98kVWP5yKidIWihLCRq wLO6kEIl2EdDuQkruwSH//BAMVplRnJ7AwPzG9EsDG56qXuDKn/p/ySn8Z5mcsRxWFB9 7XiqiRKUJevF616oTABLARU3BliecJJGteDmdcz8cRmMgLI3XwZrlS88aiw/Lrynl/1W 9DeBV4er6jNgjILt/VJJTApbqFSN8rFeuSK4lvh3So1eQrGMU1aKzSm3DjR4GUCqVd9j cWLQ== X-Forwarded-Encrypted: i=1; AJvYcCVgJAAHEKm0q3oH4F9uTIgAX1+aJfsMGt95s7BuZBjMyk4RnXr7MZof1fg147IzEkEDg9wJBy1Rk1NLVueasGCilTE= X-Gm-Message-State: AOJu0YyeGGFnJbmeECP6joXUyOFJVfavmnRs3HDAj1968hk35ZJWd2Ny 1kAxKfXTPKZO0Ite9h8UjNFuTuVA0Qe1plSa986SdFxvs2h//KukpQnzs2zBZ+MFDfgaO4drqv3 CEHw5VN7WP5gFeB0nW35hVmRXaD4= X-Google-Smtp-Source: AGHT+IG/RqYM7kt+KRNXWWffNels/XWJSltBqDKYgCfhE8HLCM9PZI9detPGXhrcKY6JSoBDOwE4NjCeFSonvB3ozGA= X-Received: by 2002:ad4:5ba4:0:b0:6b5:4865:948c with SMTP id 6a1803df08f44-6bb55a41ce9mr123582076d6.27.1722320592677; Mon, 29 Jul 2024 23:23:12 -0700 (PDT) MIME-Version: 1.0 References: <20240725232813.2260665-1-nphamcs@gmail.com> <20240725232813.2260665-2-nphamcs@gmail.com> <20240730033929.GB2866591@cmpxchg.org> In-Reply-To: <20240730033929.GB2866591@cmpxchg.org> From: Nhat Pham Date: Mon, 29 Jul 2024 23:23:01 -0700 Message-ID: Subject: Re: [PATCH 1/2] zswap: implement a second chance algorithm for dynamic zswap shrinker To: Johannes Weiner Cc: Yosry Ahmed , akpm@linux-foundation.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, flintglass@gmail.com, Chengming Zhou , Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B0B2740013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jbqfpo59f4cztogszrpfaods4z81zooy X-HE-Tag: 1722320593-424435 X-HE-Meta: U2FsdGVkX18ZtgD/VAAgV5oFuvLQaaLgUU4Iwr/RHKtw52OZnzwVxbY08jN5mWug49QaR4QGQMxdRmQcyt2lKyujKcTuvEIQ8Q2PeDSqXm0H+SZpQDM1lIJbCwgXGt4EgGAYtQA8y1222PfKiUDGz17GUkltsvl7g8Z4GtVmZht1tszNNb94BTMr3wWdxumgL8qC5IeDl3vmQuiJcVMc1T+4ZlYkCJL/2xb+FFDCnrdxEs2EV9sqH8ZOT70q4npmiKMKLOsIM1G7i8KH1PY/7DIQtsvGbrrJOK+8JTdLqrpEfMbtl8NyvSvvXwyq12y4gyOs1mjYlOLdC4tL3bTqDUWG+K/B7kLCMv7A7HINub2tuLnpJ0rKrDAum1h1rGolxM5hlQlVX+2yCcl9GhjJKClWwNovNFIEjjJTi1nL0mvOkITf2XY/yNQMvNz/+M5WuV4LjFq5U3B8CfdgIw79fy2/yuKYh3G0k5ahWpIPk8T0KyW6Go4hXuEVOTAvdtu4I9izJsy5z+XqZqTLLFiEnqF3zjCRiQIdTsfaOaFMjejJKId2Mt2QPWrV0VGXqXEwY78vpwr/IY8pTXENt3Xxlz6fv5eIBErNfI34hFMwmV3Xd4JF/xGriMxNK1oYkCeNjdqQUQmH8PKHFPGZOGJUe1NgzhpfDrAIvKvHFpB4Q/AQNXtKXm//hIoUoSzHSkFIp85m326Vt4EkVEvWiMGPjAXleInO7RCjkM9FphE/X/ImOxWIfH6cVg4hAsCJf7lWRB5ZQJo5sIbJUC+Klf4ta3wG9kZyPdoZd5w7KWoyIrnB4sOg80Bmk17HMIAVZSmAkm4TV1zL7HvmRFZkshvcErkHp0J0ysyRai9WwEsst248QmjaX8iHGYMhCXXsi1DVhZPU8kksK1RPl/Nm91DM5MxKCYdLpHGTDeZP3/5u6uL34I1MafD8pXw1k8wn4INJBpwCrHy1rPUwcxI3ybo UHUZ6zE9 Qdc/UAC1YkKaz/8CKYP9yKbJ73cgjLqdK7TbjhtrWZ2Mwn/seAxr413+77TtnXXJxxuvWlvCrNFQpFEu0KHCgM7bVDIjlGsoNHsTlJpHlJBHVwYXZz7pDG7yxYHq7l6W4vLGip1sofC0dGPk9D7wO5GOkSA5s+GqokSLw/EOHmigBONtxh+7QZni4xLReSd/xtht8ivvKR8g6xPixnF4e6uuYRAl1yEuiPpmHfFlTmlFH1cJjPeCdNaFc8jsCBQrQGUXm2RGVbJPXn+t5ZkhxDFLk9jWhwzn0qa5rQXRpQdEu7pg4W87eYa1T5y7rw/N/R7QXEzYdN4ojHSZub7MN2ZAQC39XlsR6N7RE X-Bogosity: Ham, tests=bogofilter, spamicity=0.247733, 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 Mon, Jul 29, 2024 at 8:39=E2=80=AFPM Johannes Weiner wrote: > > Seek is a fixed coefficient for the scan rate. > > We want to slow writeback when recent zswapouts dominate the zswap > pool (expanding or thrashing), and speed it up when recent entries > make up a small share of the pool (stagnating). > > This is what the second chance accomplishes. Wow, this is something that I did not even consider. Thanks for pointing this out, Johannes. shrinker->seeks tuning allows you to adjust writeback pacing, as a ratio of the pool size. When the pool is static (no/few zswpin or zswpout), then these two are similar (on average). But with concurrent activities (pages coming in and out), the dynamics can potentially be different. Second chance allows you to have different dynamics depending on recent pool activities. The recent zswpouts will be protected by virtue of the reference bits (and given another chance, which will be taken if it's used again soon), and the pages concurrently zswapped in obviously will be too, whereas the stale objects who have already been touched by the shrinker once in the past will be evicted immediately. IOW, all of the above activities (zswpin, zswpout, reclaim pressure) can harmonize seamlessly to adjust the effective rate of writeback. Without any additional heuristics (old or new), increasing seek (i.e decreasing the writeback rate) by itself only has a static effect, and definitely does not accomplish the aformentioned dynamic writeback rate adjustment. Now, we can (and did try to) mimic the above behavior somewhat with the protection size scheme: only return the unprotected size, carefully increase it on zswpout and swpin (so that zswpouts are not considered), carefully prevent shrinker from reclaiming into protected area, etc.. But it's incredibly brittle - with all these hacks, it becomes even more complicated and unintuitive than the second chance algorithm. If it's performing well, then sure, but it's not. Might as well do the simpler thing? :) Besides, the problem with the haphazard aging (i.e protection decaying) remains - at which point do we decay, and how much do we decay? Compare this with the new second chance scheme, which gives you a natural aging mechanism, and can elegantly adjust itself with reclaim/memory pressure.