From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DE1138D019 for ; Mon, 31 Aug 2026 02:28:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788143343; cv=none; b=RZ3eWsxPDEMylIaZD5oN1yO2zx1u9Y8fMV3V8IdGYSUBzxGn83+rWGq9R7NczAg9iR/Myw4thMLq6AruQ+9fln7Og2BzhKvhF5ZZHFg74FvphlbOn6k3LdDMKTZNYUNyxfMKCT/BciMTK6Scq6LvR152RNZp26qHL75PjAK6ih4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788143343; c=relaxed/simple; bh=kmlBwvRehw3VKz9c8309cNc1KVpQR1VloFEEvq8gjC0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NprxKur0Kks03LGIhz4E35z3/N4fRg7w5ntByHh/FLz3/nnSg5SsRf3W5qtup7u7v1vAAjvnuieACbGCvjeHTqWzBHI8pEQdU0zTQog9DnWVL8WvfwtMdBwBAvANdWfGw/Nmh2Sf0KyG/LzFruaVBEdlT97O9SPZ+wo/BmYaS0E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JZA/L6l2; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JZA/L6l2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31C981F00A3D; Mon, 31 Aug 2026 02:28:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788143333; bh=YwqNfmhuWrZGj3kuSG9MxCjuM4AM56GhnZE26FcBYfc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JZA/L6l2dx8QC3w5n/yLK8cpOJabBWORuQR4vbqopQwuN6VXI4pZRAfs4n5KbHiFl J8P1fRCHdch6tvgjHhqzOWtQdPei1DFyIIy5h6aEc9Vc0wuuaGQoK+Toeg5L5YKRpo DAQsTsXBN9nBJvoDMqUVkY2mMw4/sY1J2gR2ariZi7LA4XkYAAAO2sw24U18yNTVFb 6E8nu/w2hvIYgY9+ZGn6QMQBWvGPhcr8fgmKG7e0bK+oMCt8JnebCJxK30tRwzNgAT xKHpNXvy7ybM3Eh0fI4Q041VUSqpEXAuCnU9LqtH9W/BN62sGiRwA2Y4TdFlpP5lJj n2Pb3eeYfcuZg== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.ams.internal (Postfix) with ESMTP id 1507F1980050; Sun, 30 Aug 2026 22:28:43 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Sun, 30 Aug 2026 22:28:50 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGikeL7Ca+TmNEFzc0vH4jlwT722XVdXtOou1v3igBDEncFGj77NsHPEuBojySN8T oeVj2weYrB7KZMakVoVRJUPY80SNG0ySMJsIFhtHzgdy+bSF3uopPrr5hWqYy4PkJ6m2nf pwcb4EGSm5KTlkaImH9Awl16Ph6U0QciZ9hMWbDvOx2H146Eyvho7+8mPIuoEq5bRN6MKI E/ksYGeF6/W/xKluaF51v3+7WGq0uzd/3CmXvCDFovpLXjrV4gEXi+NAgkUpnMeEQCEbR5 QJmxIsRD+d1gcCwwfNdaE9dK0hFulFNDH8T+zCSx13N3x2ouJ/jP8UviWjZD7C2DjDNoT4 +ms3fM5gUKRSnswAQ/qeL0hAcDLz2QO5l0pHOFMin3wotE3xEj9F7/iAViZWIb2GTkyqar fzfGmIvro0IWJUMESur9u8YFA4GBxsqTesEeZyqhu2bXGSeKgT4D7JyolLaLb0fkai11af +KVIIGjaVpbKFdAcVQnDRnM+YVw8iKzJ8AF4qboZxMulCFJhyXtXofC2esia8N6FZmcjU+ WWC2AHzrMP4DeAACwH6856+j/kCABE7HOW/s6TpLzSa1A+kkGxtlx22K8reu4dGQY/58MS tYgJU8M4/EBvfNAjl846FVOW+brqAmI1OnITyK44vYU7Q4KiPKWTRMvnuiOA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 30 Aug 2026 22:28:42 -0400 (EDT) Date: Mon, 31 Aug 2026 03:28:41 +0100 From: Kiryl Shutsemau To: Hugh Dickins Cc: Andrew Morton , Ackerley Tng , Alexander Viro , Baolin Wang , Barry Song , Binbin Wu , Christian Brauner , Christoph Hellwig , Christoph Lameter , Claudio Imbrenda , David Hildenbrand , JP Kobryn , Jan Kara , Jens Axboe , Johannes Weiner , Kairui Song , Lance Yang , Leonardo Bras , Lorenzo Stoakes , Marcelo Tosatti , Matthew Wilcox , Mel Gorman , Miaohe Lin , Michal Hocko , Minchan Kim , Muchun Song , Oscar Salvador , Peter Zijlstra , Qi Zheng , Rik van Riel , Sebastian Andrzej Siewior , Shakeel Butt , Suren Baghdasaryan , Vlastimil Babka , Yang Shi , Yu Zhao , Zach O'Keefe , Zi Yan , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 07/25] mm/fbatch: LRU_NEXT_ACTIVATE bit to optimize folio_activate() Message-ID: References: <14a16945-529b-8bc0-ab38-3ea97e54e223@google.com> <16b39f43-d91e-7b23-900e-90cec13837ff@google.com> <7b30ca86-dca6-83b7-a632-180e35ed2a0c@google.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7b30ca86-dca6-83b7-a632-180e35ed2a0c@google.com> On Fri, Aug 28, 2026 at 01:40:51AM -0700, Hugh Dickins wrote: > Do you have a head for smp_mb__ barriers? I'm more anxious that > I might be missing one or two of those. I think the release side of PG_lru is missing. You effectively turn PG_lru into a lock over folio->lru.next. The acquire side works: test_and_clear_bit() has a return value, so it is fully ordered. But there's a problem with release. set_bit() is unordered. You correctly placed a fence in __folio_add_lru(), but every other folio_set_lru() is problematic. For instance: CPU0 CPU1 folio_batch_move_lru() folio_batch_move_lru() lru_add_del_folio() lru.next = LIST_POISON1 lruvec lock list_add() /* no barrier */ set_bit(PG_lru) folio_try_get() == true folio_test_clear_lru() == true lru_next == stale BATCHED ??? lruvec unlock If CPU1 sees a stale BATCHED, lru_add_del_folio() returns true without doing the list_del() or the NR_LRU_BASE accounting, and CPU1 then goes on to lruvec_add_folio() a folio that is already on a list. I think we need to have a helper that would set PG_lru and enforce release semantics. -- Kiryl Shutsemau / Kirill A. Shutemov