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 39FDA3B4EBB; Thu, 27 Aug 2026 11:46:21 +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=1787831182; cv=none; b=XTy3gQPJDm4SjUVK3I5Tbo0CmMLeyumSzKvHEbdLObNXnk2vf96xXHeXg1A1S6TzTUKqs/W2Gpkf6bvaq3VfuconBLIoxCKLIu9I+LZpfzg05TLl31BpPyi0950rlHsybf9cVlUzvRbV1sDSZOqlVOI40AgAl+PTHJIGePzflOc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787831182; c=relaxed/simple; bh=I93NvcT5kkpWYtiRck26P3d7syS0PgNWXwsEmndyHm4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DMsYbGwKw387L4ysw7Bfh6YkUsRg4UslQZ6ZN3HHFXBYGYA028xVpxx0Q9ElDoPTG5YiDRN8sD5OZqKaZyPhUMDXi++nw+fWLbEBGvF/TDoBxFRHC9s1OWX3buXxje8exwaXLK5QvDtHir/aJjmUGz+9rP1l84gf81EIK+/tkvM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JZ66o5yM; 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="JZ66o5yM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 358AD1F00A3A; Thu, 27 Aug 2026 11:46:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787831181; bh=1/7HEinzHyrUIuuAvpR8eRudqoAYvO5vyA5jKxjS7tE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JZ66o5yME1fjHkUhC8qyz3sJULn9QQmg4RUyDcyFvh5pQRmok0C1YQ2TuafZPYPQb JWtbSwj4EQcV51NBvZRQW4UaZNiXn9lWpvDHZLjKh7T2xZPXofeQXoFchR0+5HQR59 lODhga6ZhTFbhqSME9fa5hrdNVNodGgcgZRD9KaoCFaelL6Ygd5zyV/7W/kQjmV9a4 6IuLKGLuL+PKL/Xl4IW5Mlvok9cFkeuNgO9Wplhk9UpCuL4ltOzSP1UW9U1ScH2SVd A8RE70x7XNEVhOIIhajJxdCFAiFO6dQpzNtZvyPDUtSxXTN0xzKMp8lmAxM+UP93w7 dGNnUznYtORaw== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.ams.internal (Postfix) with ESMTP id 0D84C1980047; Thu, 27 Aug 2026 07:46:10 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 27 Aug 2026 07:46:17 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFEkFs1SlQDQdGfvtSAc9WTtr25v16L9+AoTBfiYB5jwPukem/FqOc9aBgzJGVE8s XWYu6XtTF1TiqpkLYgBAEZedvE5yRMka2V0KyqpQK759rDery0ZQGWPcpvUce4YOjJdxaU mkTf/h8DzsCePJPfrcIYp7xj1rVZw3sfyseBqC2/BQ8R8iSKLxuJs+tBOg/r6anSmnpAGj suewUpL2Xs5LkLCTflIiNIekfKUet6doHLg1kVgwEnuEEpGtXoDy4Uu5Xw+aUuWpdhdYH1 6O/Lvfm5/orsfos/smODRowOFflASWqZjIPkmpZbyHf+P2lnRwkJw4sifLopkuetjJjFkr X2dMrF2eJyqCwxQIzQ5IGiUwcFQge78u2cyfBqZkCWT5CcNVB2b34WWwQ0URExW4hkV1aQ VMa18lLChoRZqk8ZtIAQiEsxhoTbabQnXk5nEsISNP8YF0fHGnI+tuvYx2zGzPDTq2YWfF QBTdbxsbws8PYjblh48P7bR4oI+zvDgBhC8d6yjVSSg3TjuYD8biX1DTIPSj2w6fItuZ4/ iyaktA3Yvce6MXL9T9alUvd3Vj+A5RoIHjbfYs/vMt1U0WVNM6EK1igwNxqOvJ1t2DoL3n 87zY9T+sIyKV1SZpj/n2fUbPx49BE0ULFZXet8EkBdfquu52KsyYYAZPxiXA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Aug 2026 07:46:09 -0400 (EDT) Date: Thu, 27 Aug 2026 12:46:08 +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 04/25] mm/fbatch: lru bit set, no extra ref, while folio on per-cpu fbatch Message-ID: References: <14a16945-529b-8bc0-ab38-3ea97e54e223@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: On Mon, Aug 24, 2026 at 07:01:20AM -0700, Hugh Dickins wrote: > Treat folios on a per-cpu fbatch as if they were already on the lruvec: > with PG_lru set, without holding an extra reference. This will enable > the removal of most lru_add_drain() and lru_add_drain_all() calls soon. > > Recognize such a folio by 0x02 set in the folio->lru.next pointer by > folio_add_lru(). Hm. pfmemalloc (__GFP_MEMALLOC) thingy already claims the bit. Is it safe because such memory is never on LRU? Are pfmemalloc and PG_lru mutually exclusive? Do we want to be explicit about this? Like, folio/page_is_pfmemalloc() shouldn't return true for PG_lru folios/pages or something. -- Kiryl Shutsemau / Kirill A. Shutemov