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 A9C47C07548 for ; Wed, 15 Nov 2023 12:53:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1FFC6B032A; Wed, 15 Nov 2023 07:53:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECF7D6B032F; Wed, 15 Nov 2023 07:53:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBE866B0331; Wed, 15 Nov 2023 07:53:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CE0846B032A for ; Wed, 15 Nov 2023 07:53:57 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A7FAFB5B13 for ; Wed, 15 Nov 2023 12:53:57 +0000 (UTC) X-FDA: 81460180914.22.2FC245E Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf06.hostedemail.com (Postfix) with ESMTP id 20C47180022 for ; Wed, 15 Nov 2023 12:53:54 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=YnCtMiVD; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.181 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=1700052836; 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=MuyikNx6ChSG02AxULm8OQDXCsKtdigfSeQkNQXENcI=; b=0qOkUnRnH+78ejmVqS6HBFxu00j+o7E0sXp4S/EHel6k3chpHlcIM08ypF5HEQnIRdguZQ dNhNeZZQbg4MlVyuYQBohYCi0hxSBNCj7iX6JD81dzcZAd10xnl5tqFntYD8La96aqqJUe hRzdluybO2N/1WvjnFmSEnKFwdtV1fk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=YnCtMiVD; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700052836; a=rsa-sha256; cv=none; b=Rl23JZ0pN26r2hWfu4Os1DxScfY9+AVEXg7dNjoPpuHA5RnfEPyCIiD73PigmQLwR6khU4 NM/fKHeUAlFwaQT/BNwhuVtP0Io7OEJ+VmrghZDY1i0lMsTxSyyd08hCWTAdD0NGL3bzKW gZViYSpTsA5go6AQKhjLt48rpQyuDGw= Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2c6b30acacdso87614211fa.2 for ; Wed, 15 Nov 2023 04:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1700052833; x=1700657633; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MuyikNx6ChSG02AxULm8OQDXCsKtdigfSeQkNQXENcI=; b=YnCtMiVDj1fyvnCDviLjQ9CHhBFXtmCixyw60dD1cSNTgcBtnvdPZ1085/E5ecs4cW iWzB/pSX4h+5Yg6ALJgjMcFCX38XoVggekBJvCh4XMTZEHE33IkoyrVvk3fWoq3mpOLp MAnl3qt3TTT5N2yolDodD+eU5ClttMHsJGZruiOD3NDWEfzy2qJD7o/8aODRaK4uB9cy pfwKXuBXHIaq3wbE8hI57PRQ6x0tsdHlY98QS9//KPBaXZMgbHmaPWEFtyJFPCllJU/X kvGZPEHIIK/vbdnhpUoZRhRiwMMhNydN9E3Ka2QFs5/PHKflOOzgj8MjjoIuUyFfmdbF Oshg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700052833; x=1700657633; h=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=MuyikNx6ChSG02AxULm8OQDXCsKtdigfSeQkNQXENcI=; b=X1TEvQst3sznjHb7fB5m0ZLufb1QSkovoJ0cwhCdRqi7NGTysUrPNamog1Kq33fQH+ BYqiDco+X+lL23Lmvv4u8zjAiWiSTHLjFUh/sA74pp4ri7aM135DmMGRviKlu13ZDdmW Vs8GLjhuNMv8y9TaDNXdqJZP45Cyjj/n8bjGQoG5Oc1GtEkpWVyyhTEesfzqSwvjmdmk hxdxA+5TSSjza7HWu1kDz46TH11qNHm+EsiKaXH31kjyWTpjcZuLrVIoLitW/GQCS1C4 z9hj831vbymD9csNy+cbF8SDDNIoRFwC504+CDIW1Ua8po6UXCo0DatufvUvEHydT8nH +5ZQ== X-Gm-Message-State: AOJu0Yy4VMrEs+pDSOSkDp81gT3q2U6hZ0ADXNmxKIl665DBZDlx+EL5 WKlRDJxtiYS5xFIuZqmkYhVRI0DxJFMiG6Kk0tGdkQ== X-Google-Smtp-Source: AGHT+IF5esqszkwCy+vMIqhxdZ+dWLL2kmA3it6yqtksXWLX0V9SWVGIU/6hzusvlrBtpLEbL/wb47EGvlhdUZ3GGfA= X-Received: by 2002:a2e:b607:0:b0:2c5:18ed:1802 with SMTP id r7-20020a2eb607000000b002c518ed1802mr4063420ljn.34.1700052833082; Wed, 15 Nov 2023 04:53:53 -0800 (PST) MIME-Version: 1.0 References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Wed, 15 Nov 2023 20:53:40 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios To: Yosry Ahmed Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, nphamcs@gmail.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ying Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 20C47180022 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: fqptdtajgeu6m6axnxoxt6ghg34f7sjm X-HE-Tag: 1700052834-80275 X-HE-Meta: U2FsdGVkX1+aFIyU/wNB0AeGBYzOrWji03gZBztHlVWDm/S09bvYA3Q1VYouf7Bpm0+L8LPaQduGwPXT4RgJIKhoS8LMOCTzzvCRZkwKHcm8PaGRu0njbn2g5W7NMXN4IdDNCMsnBcP1F5awtOl6069qBE7KpEiZn4ILC5aCQ2BfVTOVdoSLQDtRInHgMB7u4lyNXInBE8oPu0M5NVzptty30xMxBgL499HStB2p2ucR+ISEOJeyVP83r+40VmNkqqdhvjMyctwjfyX2aBWBe9XhMtflwibTPvaTLU2q+fuYWm6MoQLPWo1NnF6Tl3aaCU/BAfk/4nOLf0ki8U+BCTqr8OLHqMaXakCimOFg9Kev9PRT6qWnqKw7vkaI/aCcazqHuQW9Kl5YhJVDbpmyTLTQ5nMj7N8IH661pX9Z1xPdFAG1vt+jIq8xt1qYmSkVM/Z7F5L7lkjnk1x9Zm7e3+Sf7gbcU8eHCxZE4vKM5eekEiXBfK19Cf+0UnbpvPxtkytAUK7eL9NURGAay9MFWgTTg7P4LS3BV9HbHhfFkBUiC1uhrgXnQmM5TtsjZMchndGGChRjfZ5Ed5o+jcDAhqO4g0PVnSFNAf4cpWmZKdO6jVHaXcSwhe2z8bMY4OeoWUMaJ/yv0qQGFlVgNTGAOPGhjhMDSydWzC9CAxeQS89LZxHss6HhW15FQ8nc6fd8MZhYYB/CTQgSnZpatvop56/QUzpBXTReNqlO4RtxrTRR+DGLahoH4U0ZanA77+LdhXP7rcCOPokqqb5qaO3kdDsiJDrODA9SQWWLXhwZnZ7XLA1DZzZJl7VaK9R0MHzaD1nzqytTEAaDCWOIS6lADNtcNaYvkk3IlqWB1j4MHjbO1Wq6AU0sgrp1WcINnqGw8YGlp7v5SO0OSWYxE+Qr+5Z1A5Kv25HoaY0Pe077K+qYIYbSzUyBDgpS8rOYFMuXfN2Kakn2GXN2jMjwPgz H2CxyE4n 8B40f8cM0PTKMGqSW4uYyWN4uSDSywJ8uX6Z5s5gCgjm9VLTJIJvvsoik8+CeValPeawoYPwYJU1FT8m8M9uNgv53xydSVbaXEYOLOCpJLA5nQSks909xZXzfrjIxnBVC2k88wE/4/07BkWNnA5Bk/4S7rV6M4xum678tIdRC+Ky21lU3qApELSrhLpz/mNMk8iVpttPoHJiGJhtxoGKc+/+vNZ7KLumSst595mNxhflA8rQCorDVuJFaXIJ90FttIgd+CYC4+YRgjjk= 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: > For case (1), I think a cleaner solution would be to move the > zswap_invalidate() call from swap_range_free() (which is called after > the cached slots are freed) to __swap_entry_free_locked() if the usage > goes to 0. I actually think conceptually this makes not just for > zswap_invalidate(), but also for the arch call, memcg uncharging, etc. > Slots caching is a swapfile optimization that should be internal to > swapfile code. Once a swap entry is freed (i.e. swap count is 0 AND > not in the swap cache), all the hooks should be called (memcg, zswap, > arch, ..) as the swap entry is effectively freed. The fact that > swapfile code internally batches and caches slots should be > transparent to other parts of MM. I am not sure if the calls can just > be moved or if there are underlying assumptions in the implementation > that would be broken, but it feels like the right thing to do. Good idea, This is indeed a clear solution. I'll try it in another patch later. > > For case (2), I don't think zswap can just decide to free the entry. > > In that case, the page is in the swap cache pointing to a swp_entry > which has a corresponding zswap entry, and the page is clean because > it is already in swap/zswap, so we don't need to write it out again > unless it is redirtied. If zswap just drops the entry, and reclaim > tries to reclaim the page in the swap cache, it will drop the page > assuming that there is a copy in swap/zswap (because it is clean). Now > we lost all copies of the page. > > Am I missing something? > Ah, my bad. Missed the step of marking the page as dirty. Please have a look, just like zswap_exclusive_loads_enabled, set page dity so that it can be pageout again. if (!page_was_allocated) { if (!count) { set_page_dirty(page); ret = 0; } else ret = -EEXIST; put_page(page); } Thanks for your feedback, Yosry.