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 3263BC4332F for ; Tue, 14 Nov 2023 05:21:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A042D6B02B1; Tue, 14 Nov 2023 00:21:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B4146B02B2; Tue, 14 Nov 2023 00:21:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87B946B02B3; Tue, 14 Nov 2023 00:21:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 789CE6B02B1 for ; Tue, 14 Nov 2023 00:21:49 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4B57E1CB62A for ; Tue, 14 Nov 2023 05:21:49 +0000 (UTC) X-FDA: 81455412738.10.333E610 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf06.hostedemail.com (Postfix) with ESMTP id B894418000E for ; Tue, 14 Nov 2023 05:21:46 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LQ352hxR; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699939307; 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=rFazJKGI/TXOxXxvNJdTYDm70uzaXwkwGyJYAesZ3KA=; b=QLIH0oHnWD0cxFCtwFrdmN6CVUVthgfZjl1tS3GUe/pljmRWV+5r4dk0PN/0+E9mEOtPJ+ MdsrqUsYwyj40OdXuhS4lZ/ovQtKKAdvAtYT7IEwXnfvME83bAWYwua/GQjK+q4h8rhnpr j9hGNOl+CB3BwqxW84I9OfKtl5f35Tg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LQ352hxR; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699939307; a=rsa-sha256; cv=none; b=QGHPRHELJKnSgwcFr60P6wMqzfVIi/pHWdBcyAh0IWpANp+Qz21ZvqeuZekhLZcwIQw27g cA+VBgCvNRmu4coIIor7pED6DADkVEqx+XB7kSj+hPWObvwMT38Npotz3Zuxq1n0I6thfC Yw/EPmxfnRLh8drKwyzuK2P42p1sun8= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2c54c8934abso70338271fa.0 for ; Mon, 13 Nov 2023 21:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1699939304; x=1700544104; 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=rFazJKGI/TXOxXxvNJdTYDm70uzaXwkwGyJYAesZ3KA=; b=LQ352hxRqkSw5Pw1uP0/xFe3Z3RHsJzCfcwB/GS6Ziv5OEugHsOSL6AA04qUXSEfTP QV2Qa24Hpa6MJfmXnFdYRWO1Iy2q8Dh59zLe/V9dnpyoC/3rjHUp2hE+ISnE13VwFBIF 2TzmBnEeeHULOofz+ZjtekIzBtxFb6+Z5dKnVaRywXvABykSB6Noyx32iuUjz/X1mn8W pGjWBanjI3g3gS2fgbzCUn/Wc4K7ASP0DbDzCCiflSEthoxmPcIlikScZ0hzcNCR7f22 v5bxPXLZoXMV1EOacuGT+ifLknH6BhYtIFRpczP1EwYMyN0tTHvuzyW2JGR65QNPzlvB uRlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699939304; x=1700544104; 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=rFazJKGI/TXOxXxvNJdTYDm70uzaXwkwGyJYAesZ3KA=; b=iDoHrzoWyySnWiGsoFjbdtbAEXS/22fmsLKOWMX9EOzIOfvL3ouKo2Q3fLZClCjYy1 08Ih85xyzAbSHUthlA+oO1zNJXAol4WDMsc/bHU7oMmSDectazkCXNOU207M3w4z4kB9 oP0/Jty45+T601rSJz4/53NE0vGTyBIZQsRd4i7g/uCLwgKRKyE6oqltpzNl8KPyGopA 5Uwwqw+1d9AmfA5w8uMxQaIlzMSZH48VpS7q9r/pOGuiommycrYks32fhzOc+eHEr/3o UzOBm+BrcJjwrpz47Ahf9+6BN5r+X06ABYC7V0O5ybGrsWdn8qQhoQGfJFlqoPCDXycx XDOg== X-Gm-Message-State: AOJu0YwQeUeR/QWNu6/7iF9sgbVjVfWOnYZD/7RW1NK2OaS9DHMeIKkg Lev4Y/PiCCaJT4p9jNnuhAlYbYj9LajwnbqEI9dWMw== X-Google-Smtp-Source: AGHT+IEJizqJ/1ImGcgFDonHZweB1Xt1y6ltaxyQoL5rns/lM33U5zyLoo2f0MZnaq+ayEER0/f39NPIgR+FBGZcMzY= X-Received: by 2002:a2e:a175:0:b0:2b9:4b2e:5420 with SMTP id u21-20020a2ea175000000b002b94b2e5420mr817711ljl.52.1699939304588; Mon, 13 Nov 2023 21:21:44 -0800 (PST) MIME-Version: 1.0 References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Tue, 14 Nov 2023 13:21:32 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, 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: B894418000E X-Stat-Signature: 1rgz5okt3hx454p68grxx34qceftmgjx X-Rspam-User: X-HE-Tag: 1699939306-285119 X-HE-Meta: U2FsdGVkX1/mcoQMUCMUL8i9D/hvg5SBqTqTY84/SBtWx5Zxmp561eYDYZjmcdvHp8nuDCfcGqCqjyyiJnrm8wMCIplkO/1KvX0sVMNpi0cG9afpuHHa6D5S0y16nnSUmqt4Z6CnS520YW+aJTthU4dLsBlgVjxLa3JxjSHc9o8jYfQA+9EdN3J32WN90ci8d0yVIovsHbUffDTHArDeSRXm39Rta07RhpyK8h1kUn1SQND2F1w2EY+FAJSb3xw1Afi6cW3jEADvpmWK8CXlZ7FCsPLAXBzpRamF4ZxhH/r6RI7F//4gOuqE6lKWaWhrEuUHYnOdHrHdVDRKNlRiV8kqGP1PKtqO+PYsGcp5boUwPMY3Uk5z2D1owl0+NTFiXnkkVLfj1QrYOHJ9t5hnX9h0CltbSpYs3Ede6hWyoqaDigLSRTMU7kZ46uvBQoKqwQxVCGtK6jRE9tYFQvPDuxfHqQPxG7Kmz1xAuLK8gvNVub4YGpXT3hfWuQ+IYcIozXlFt2seUMV2ziyAgK8HICHzzcA4muMGkfBwqcTj2EtECKV5aXhNP8TmRvci+0FRtQ/FiXNIWNj96yjZxgIRSSpR+W80Pb3Bm18CIo8k9qSDKVziZvu0JOnIo/BZdVhAkU/9xBmYm7AUeLGy2MtncOSyhHzBgcapY0j4ad6I72tjJOvbPmRxf2Q2JQ/dYOqhIDeuivWi5HF8XVPZ/hkbUlOLGYXev/uMedMusO4yWW/ztheBzX31jrsX1swIvbT9IYjr7JEIM6IzvwvLKXWukDiwdW39cXla8d233C6kOOr0WNY6rn5DojSQGsKGGM4SUS0oRZxHUPanR1oCnBoovZQVOD4/Um9jQazy72X9uuSnKgrVn41fPP7ZbDBBnLstkqK95bcBCP8Rvdy44BC7blPtKJqnQghOl0khNcMJ6GmWadoivb8ZbeWCoaZ0KbLLQU4h18+OT9GhhVCekaP YTiuH2DZ 5x26NIRNB/qLy5FQfl//YWjwe68nHKZRwUP6ySzCgpZcVAh0u8tBJw6qAYC5LjGn5ur+F9rrFB2jRJBu/5ATNvO3ryXRPK5wovl5FNXcvUStvoYK/7zas6XGVKbThvT0IStplS3pjz+xVJWToQ+bbRldXbXnsXL7syJ2jBu10I3iHjb4h0qM82p6WwagSQnWmyVXPtUSMditHHKHau54aZwnwDt3zNZNhFWzi X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Thanks for your time, Nhat. > > These two cases should not count as "successful writeback" right? > This is true from the perspective of the writeback itself, but should it also be considered successful from the purpose of the writeback, i.e. whether the compressed memory and zswap_entry can be reclaimed? > I'm slightly biased of course, since my zswap shrinker depends on this > as one of the potential signals for over-shrinking - but that aside, I th= ink > that this constitutes a failed writeback (i.e should not increment writeb= ack > counter, and the limit-based reclaim should try again etc.). If anything, > it will make it incredibly confusing for users. This patch will skip the writeback step=EF=BC=8Cso the writeback counter wi= ll not be incremented. Currently MAX_RECLAIM_RETRIES is 14, shrink_worker will often fail if writeback fails. > > For instance, we were trying to estimate the number of zswap store > fails by subtracting the writeback count from the overall pswpout, and > this could throw us off by inflating the writeback count, and deflating > the zswap store failure count as a result. As mentioned above, writeback counter will not be incremented. > > Regarding the second case specifically, I thought that was the point of > having zswap_exclusive_loads_enabled disabled - i.e still keeps a copy > around in the zswap pool even after a completed zswap_load? Based > on the Kconfig documentation: > > "This avoids having two copies of the same page in memory > (compressed and uncompressed) after faulting in a page from zswap. > The cost is that if the page was never dirtied and needs to be > swapped out again, it will be re-compressed." > Yes=EF=BC=8Ci know the point=EF=BC=8Cin the case of reading, there is no da= ta update, so the next swapout does not need to be compressed again. Consider this scenario,there is a lot of data cached in memory and zswap, hit the limit=EF=BC=8Cand shrink_worker will fail. The new coming data be w= ritten directly to swap due to zswap_store failure. Should we free the last one to store the latest one in zswap.