From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794579487; b=TMNuK2qkoBRR5oMbOhqFZ8zprJ1GtEW65FDF6KfB35/e8IFykYiodnViMBiUd7AMqPbb ewFFEWqTWbXMRZ2Bg/UlcSz20o7HjCzEbyaEGhmWZ3QlR3LkJTX1jvjpYphZb4UVGUoaG SxMucypMfMdOgN1Ai9heb9LofWa/Sq0p95nAwN6c71UJ9gEzlc2ebN0XTPlAQwVJlgh3e EKhhaUF+Vyag3GalIbmvUaxWtG0F1kGb9ZeINvEZVNUkYGr25uCkZ1I3T7dztlsRgta0c KVQZm26ECWJjTWQmFRgCbPSSbiOXWSVr7RIhj6Che4BJt7KTbLlCOnu1Ku2vcP/SxJA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794579487; h=Received:DKIM-Signature:Received:Received:X-ME-Sender:X-ME-Received: X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=wmO8NUyn+tw3LA8pc83LOjgpNgEXt2U57dJm4LDr0Qs=; b=dmjVajexbEwyvUSP9la+Ao2ysk4IcHjhFnwoxc4g0TJ0iRpig+r9ajFVufh2ikPGM+2l LAO1pK6SDRr0PNHeByN720lmyoFBZLmSv+1Wh2ap/r/NPWbnHbb0HBT2VN7iOgMXTUUnc IO0IsX252aZGYHio71opc2qz0JZMdollMAFMXYqwzscjA9rw191iV+xBiMuIQObPplvRC Gs8J3gKiaooaOZ2rsYrr3r1yj1plQEAD1vu7sECMHlS8bDN6UrSEA0xGhxWXwMDNc4jvi D7randOGHBbg9WJy1MlvsMFgRUGjcbew7mVXPCXNRqA5ORL+kWZ+TUvbd7sW+iuzKLA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=GD8xfZZ6; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC9C2606A327 for ; Fri, 13 Nov 2026 14:18:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=GD8xfZZ6 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD9A31F000C4; Fri, 13 Nov 2026 14:18:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794579486; bh=wmO8NUyn+tw3LA8pc83LOjgpNgEXt2U57dJm4LDr0Qs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GD8xfZZ6MYl0IGuYyHhFAnauT4OtFk32JIXgpTiHI7EqSSQ7XEAno6vGt3dHVqb1W AmkHxMCfcONSeeJy4uHIl3HYUXDrKmf+mTdzP4pPEW5bp84+3V7uoBaswtYY6zHw/v fC7LTH/OkJAKQDWWIY8+hFLMPF2WDsjTwMkJK6RGmO+UcAZ5BHVvr8Ozi/VzZLNT+i rNkdegz8FyaUaNXoBiJgTiq/KasB3nfmDfN80pDjEzWVvKkVvyxcXzEB/bLDODVinc L6yJVb+jswur5EZK7gk3ox5kTWCOKW7bPxk8RTenuj7CAgA3DnVvD0O1ZcHI7eNKM2 nAmuiOZWWo1nA== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.ams.internal (Postfix) with ESMTP id 23A75198003A; Fri, 13 Nov 2026 09:17:55 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 13 Nov 2026 09:18:02 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEzMCqVlLYFNyqlxeWBK3QY4hUxX3AkiisQ6Wsz8rpHRtq4ZcMku0cF0La3OlvjnX /xfBuVvDa3RHdhPiwhvWLpjLqrjGEGADEqiOHV9/JXSwTz8JdIOh/PEHYmMrRbqOyF2B/s 5wTS+jpXngPrQ7qt+MCEkT8tOUYG65L/2UMjxT5FV9coWU6S3yGe/kRrXja/Fw4iIzf9HL wqHvIk5iIbUxzWZJ1djtF/fN4ey41t+TF9WgvIk/Vj5Lbla0oBToXpnmcTVMy4XJtn3mRc 8CR2ix91u3bcsoeFp9EhIFd7g7xAw5JjSY1e5qWfOxQybGryE8O5y6QyVEMNM2DqWerEik /HYvMVEChadsXI1kuhw+cn+noZvDIArvO8rrybl27CPTT2g/Tp2TxV1iQbVkjEZfztr2gf u5PqCUtFGr//dBWYZ5+GwJFSuzuVjNqw1GpGGGwIfQbVnHTEU3e7wOAr4MBMiZPsqsLdhU WQTSCyvBE3aUamUav3yX7wDqK32rtzmJOtXH9ci1O91APr1HcwtJTBaQ7wOp/8rl4afBZt rjHcExMGuudSGnR3Qflkg2k4sfH/Ici0rFMsifOVe47kiQzvkbIJOc8Ufu5Bndys3rjsB3 zcij66R3Mj2tZNL+JtX4Pbw64q+UFyW8/eSkIkJINPnxWOc0o+sVZvUCCxjw X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Nov 2026 09:17:53 -0500 (EST) Date: Fri, 13 Nov 2026 14:17:52 +0000 From: Kiryl Shutsemau To: "David Hildenbrand (Arm)" Cc: Linus Torvalds , Andrew Morton , Matthew Wilcox , Vlastimil Babka , Lorenzo Stoakes , Jan Kara , Hugh Dickins , Christian Brauner , Alexander Viro , Harry Yoo , Miklos Szeredi , Miaohe Lin , Naoya Horiguchi , Oscar Salvador , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Kairui Song , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , "Paul E. McKenney" , Pedro Falcato , Luis Chamberlain , Ilya Gladyshev , Jaegeuk Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, fuse-devel@lists.linux.dev, kernel-team@meta.com Subject: Re: [RFC PATCH v2 01/18] mm: free PG_rcu_free folios only after an RCU grace period Message-ID: References: <20261104130118.2507513-2-kas@kernel.org> <8504e28f-faeb-41e3-842e-0cb74d1a25ad@kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Nov 12, 2026 at 01:32:02PM +0100, David Hildenbrand (Arm) wrote: > On 11/12/26 13:26, Kiryl Shutsemau wrote: > > On Wed, Nov 11, 2026 at 11:03:38AM +0100, David Hildenbrand (Arm) wrote: > >> So I might be completely off, but what I imagine is that the memdescs will get > >> RCU-freed (these are not pages), and once they are then getting freed, they will > >> probably take the physical page with them. > >> > >> And freeing memdescs through RCU will likely be memdesc specific. > >> > >> I really don't know, Willy might know more about these plans. > > > > Right: once the folio is allocated separately, the lockless read > > dereferences it too, so it has to wait for the grace period along with > > its pages. The per-CPU batching and the waits in the allocator later > > in the series do not depend on where the check sits. > > > > Until then the folio is the struct page, and __free_pages_prepare() is > > the one place every page cache folio passes, so v3 keeps the check > > there. > > If we go that way, don't make it effectively folio-centric in the > implementation. That's what triggered my response in the first place. Is something like this what you mean? diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d3862d68a8d9..5b9ac91d25ae 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1314,7 +1314,7 @@ static inline void pgalloc_tag_sub_pages(struct alloc_tag *tag, unsigned int nr) /* * Each CPU has at most one grace period in flight (@queued), covering - * @batch. Folios freed meanwhile wait on @pending for the next one. + * @batch. Pages freed meanwhile wait on @pending for the next one. */ struct rcu_free_pcpu { spinlock_t lock; @@ -1354,28 +1354,26 @@ static void rcu_free_take(struct rcu_free_pcpu *r, struct list_head *list) static unsigned long rcu_free_pages(struct list_head *list, bool direct) { - struct folio_batch fbatch; - struct folio *folio, *next; + struct page *page, *next; unsigned long nr = 0; - folio_batch_init(&fbatch); - list_for_each_entry_safe(folio, next, list, lru) { - nr += folio_nr_pages(folio); - mod_zone_page_state(folio_zone(folio), NR_FREE_RCU_PAGES, - -folio_nr_pages(folio)); + list_for_each_entry_safe(page, next, list, lru) { + unsigned int order = page_private(page); + + set_page_private(page, 0); + nr += 1 << order; + mod_zone_page_state(page_zone(page), NR_FREE_RCU_PAGES, + -(1 << order)); /* Atomic: memory_failure() may set PG_hwpoison meanwhile */ - folio_clear_rcu_free(folio); + folio_clear_rcu_free(page_folio(page)); if (direct) { - __free_pages_ok(&folio->page, folio_order(folio), - FPI_NONE); + __free_pages_ok(page, order, FPI_NONE); cond_resched(); - } else if (!folio_batch_add(&fbatch, folio)) { - free_unref_folios(&fbatch); + } else { + free_frozen_pages(page, order); cond_resched_tasks_rcu_qs(); } } - if (folio_batch_count(&fbatch)) - free_unref_folios(&fbatch); return nr; } @@ -1421,17 +1419,20 @@ static void rcu_free_expedite_workfn(struct work_struct *work) count_vm_event(PGFREE_RCU_EXPEDITE); } -static void rcu_free_defer(struct folio *folio) +static void rcu_free_defer(struct page *page, unsigned int order) { struct rcu_free_pcpu *r = raw_cpu_ptr(&rcu_free_pcpu); - struct zone *zone = folio_zone(folio); + struct zone *zone = page_zone(page); unsigned long free, waiting; unsigned long flags; + /* For rcu_free_pages(): not every high-order page is compound */ + set_page_private(page, order); + spin_lock_irqsave(&r->lock, flags); - __mod_zone_page_state(zone, NR_FREE_RCU_PAGES, folio_nr_pages(folio)); - list_add_tail(&folio->lru, &r->pending); - r->nr_pending += folio_nr_pages(folio); + __mod_zone_page_state(zone, NR_FREE_RCU_PAGES, 1 << order); + list_add_tail(&page->lru, &r->pending); + r->nr_pending += 1 << order; rcu_free_start(r); spin_unlock_irqrestore(&r->lock, flags); @@ -1452,7 +1453,7 @@ static void rcu_free_defer(struct folio *folio) } /* - * Free every waiting folio now, straight to the buddy lists, where the + * Free every waiting page now, straight to the buddy lists, where the * callers look for the pages next. A concurrent drain holds the lock * until it has freed what it took. */ @@ -1528,7 +1529,7 @@ static __always_inline bool __free_pages_prepare(struct page *page, !(PageHWPoison(page) && !order)) { VM_WARN_ON_ONCE(fpi_flags & FPI_NOLOCK); count_vm_events(PGFREE_RCU, 1 << order); - rcu_free_defer(folio); + rcu_free_defer(page, order); return false; } -- Kiryl Shutsemau / Kirill A. Shutemov