From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAD493C10B6 for ; Fri, 21 Aug 2026 08:35:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787301334; cv=none; b=EuadiA+Idg7AuQf3BwWWwhmBhGxRVzPPK81mAHXOAH5B5trqkLAkVETWvyT/xN0mEwdjVANJ0/ZSzUb96rVhHiglZ2Z6ZMGlvlGqrxAskrZe8hi1xj90QAy6iUYe/ZzBJvhVahHGOCEhPSzDicM1dG5k/4yGESzIyyujWe7/YD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787301334; c=relaxed/simple; bh=youOxFVddrhWr74tg/MLalhJaYF6HucpgLWmoRiHfYc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z7PW4iZo307481YpFEnNMhZqxnvU7T78RW+BAK4p2GFlkoCtuVACt9iGK0UABZR/SzmGo+L4KKvj4X0XWbAYJ4jQSrhP0dNFiOwh1rIRKLDsqxMDAWBQRox5D1ThJyNikh7cJXpnFCh76fR0rWYCzUV7BvWy48MEwWKsJVNRnvs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RxamdwQ/; arc=none smtp.client-ip=209.85.216.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RxamdwQ/" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-38dc69c74b8so731950a91.0 for ; Fri, 21 Aug 2026 01:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787301332; x=1787906132; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LJo+VFODNoZcuVrRZgNruXYVosZL9AlBhzltP1KWSy4=; b=RxamdwQ/o+iHZjf2cbDgYvTLBo6TSCw2/7spKkeYqNvOceWan8F8W0Kl41ww2Bd6jw u9ujmZn+fgZrPL/zjnZKyHAHU8EPIj2E6fld7HiJn4jWQq4LjwZSe6tQfmvzPlUfs/74 C388uu3AlWESftK3e2FpN2lXQnaHjtlZPKEwen1UuJIygHRZQBENXYD/5Lj+sqvZSI18 8+ahjloOvV/BwlwrjVodQO5/7Irpis39NcFdBJP9B8XhxytlGNmicX6ACRL8lorfnJRg l2QSvLnZh72uyjf+ps5OmJd3IDkGcmLRHUyS6/ypftT1wOoEHcsNXlC1as9vyce+UX8M 9xoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787301332; x=1787906132; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=LJo+VFODNoZcuVrRZgNruXYVosZL9AlBhzltP1KWSy4=; b=XgK9E53r4ROr3kZG6DPQ6nkpLJW7dgzXvkgU5iIMpd9lovZCpwXBs0bHNGLkQ2eKj9 wo07nW8TB+ZdgNoMRrJEz77e3+xommbgO5DHmxrh8X8Dg14QFLT4ocvPR0zT9pw/LNSi pa8cbMGEqm19f01Mt//FcIXEeADlVHkLzAjP3BLzkPCjmxzKxpiP03eiO3hnoc40e49l FzgosS0as7kij4mxfWcTfrYoqlzucypyBXwzhlzrx3OQlzSNgbIBAX5L0im/dJqm4h4D AZiRScsRFTIbxOzrfIa682ZsqPfEa4lmMhOK30fZS7jwNs5KsRtPYP7axbC6/zpemGBl MYVg== X-Forwarded-Encrypted: i=1; AHgh+RpPZMDtYlm/0bgHI8yVTPvNwc3BA/shDvUuXBzN15EfiGGOlEilFn6hUuseJw4PyCBWPkHWVnQbDsIXJZk=@vger.kernel.org X-Gm-Message-State: AFuF++nmwNh17AkOnnVRBtzIhEbFh2p9MbFZXfEw1dVfyozIMRqMo8l+ ckEIYKdMJo+dQDesoBJHnA3RuD/DCDP0k68erjLzObC25obOvorx062R X-Gm-Gg: AR+sD11zk1glr1GS4XDyAp64VjgJbkIDz0LQCycraHpFlGWQ4NjRDQztXuFblqZO1wp M+G3q33yzIUIy8FlxvISWKjMd57QieEQ5mCeRrI30jZ/O8HyReaW6AsDyUmQn5uKEPDeY0Ujsas dQ413TkRfbjEIjaSFyiY2Uun5aI1XdfKGAekXliVdUN0Zk656zVN454sgvslIPoibqZAhXhodN1 NybWZcgwjeZ83TCDIMX9UbBSL+2UwWNdvLz/gg02TaAMmv4JSTqgYMTCmWwOomZV8aLD5lXbX0r zu3LwcceL3nLqAioSbD36kWxmMzbY9Xcu1QJ6AhqFraicGsqFFvJWw19SzuX1Ke/iRxS0i3gY5H h++ljcBhXRJq8sKjoKNL0t1tCcn3EpvBQDsGFJE7VChmqyrCA2EK8LNKZz3MOBYluC1Qk2CbVxI PI85NFYkPwJtmi/h8i4lyfB53KSOYM6RYy4faoz3JBLoDrkNNqFiU1HJwoi1OXq+6aZ7/bkvmvn 3gtGEQ= X-Received: by 2002:a17:90b:2f0d:b0:381:cef1:11ac with SMTP id 98e67ed59e1d1-395c3561a6dmr9048161a91.10.1787301331934; Fri, 21 Aug 2026 01:35:31 -0700 (PDT) Received: from kernel.tail6741c6.ts.net ([116.128.244.169]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-395c8fd34d9sm599575a91.1.2026.08.21.01.35.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 01:35:31 -0700 (PDT) From: Kunwu Chan X-Google-Original-From: Kunwu Chan To: Alexandre Ghiti Cc: Kunwu Chan , Johannes Weiner , Yosry Ahmed , Nhat Pham , Andrew Morton , Chris Li , Kairui Song , Kairui Song , Chengming Zhou , "Matthew Wilcox (Oracle)" , Jan Kara , Kemeng Shi , Baoquan He , Barry Song , Youngjun Park , Alexander Viro , Christian Brauner , David Hildenbrand , Lorenzo Stoakes , Michal Hocko , Axel Rasmussen , Qi Zheng , Shakeel Butt , Wei Xu , Yuanchu Xie , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 2/3] mm: swap: drop dropbehind swap cache folios on writeback completion Date: Fri, 21 Aug 2026 16:34:50 +0800 Message-ID: <20260821083500.856970-1-kunwu.chan@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260818163221.589352-3-alex@ghiti.fr> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Alexandre, I have a question about the reference ownership/lifetime model in the synchronous-IO case. Consider the synchronous writeback path in Patch 3: zswap_writeback_entry() folio = __swap_cache_alloc_folio(...); ... __swap_writepage(folio, NULL); folio_put(folio); During writeback completion, Patch 2 does: folio_end_writeback(folio) folio_get(folio); ... swap_writeback_dropbehind_folio(folio); llist_add() queue_work() With synchronous I/O, is it possible for the dropbehind worker to run before zswap_writeback_entry() drops its reference after __swap_writepage() returns? If so, the worker will attempt: swap_dropbehind_drop_folio(folio) ... remove_mapping(swap_address_space(folio->swap), folio, true, memcg) while the caller's reference is still held. Looking at __remove_mapping() in mm/vmscan.c, it expects a refcount of 1 + folio_nr_pages(folio), but the extra reference still held by zswap_writeback_entry() would make the actual refcount one higher. It therefore looks like folio_ref_freeze() will fail in this case. Is that the intended behavior here? If the removal can fail, the fallback is: folio_clear_dropbehind(folio); folio_add_lru(folio); This appears semantically safe, but it means that the dropbehind optimization is lost for that writeback: the cold folio goes back onto the LRU and has to be found by reclaim later. This seems particularly worth checking because v3 intentionally removes the synchronous-I/O special case from v2. The cover letter describes that special case as an optimization that was not worth the extra code, which I agree is a reasonable direction if the generic path is sufficiently effective. Could you measure the corresponding fallback rate on a synchronous backend (e.g. zram)? The 99.996% success rate in the cover letter is for asynchronous NVMe, so it does not tell us how often this particular race occurs with synchronous completion. More generally, I'd like the reference ownership across __swap_writepage(), folio_end_writeback(), and the deferred worker to be made explicit. If the caller's reference can overlap with the worker's reference, I'd also like to understand whether that is an intentional and acceptable trade-off, or whether the overlap can be avoided without reintroducing the synchronous-I/O special case that v3 is trying to remove. Thanks, KunWu