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 ED3383054E4 for ; Tue, 1 Sep 2026 00:24:33 +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=1788222275; cv=none; b=IrWns3FZ+/AvcAzz3kzKaMSC05Y5Gc8egCRb5RERxCssd7tVjx1m//7I1m9NweAvDAatGHR0G5L/7rbM2sxdrca05Gf16Ttu/5V3TgoUuEOCEBi6D6UdQDGMfMTVtL5ZHG2wEDwuhoTjYnaguk98JcZ0yNGAhAKVXp2T82FWzgc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788222275; c=relaxed/simple; bh=Xhz7EkDMBk7W5Nu9uvM5F+kml6LCokS2NoQHnsJjScw=; h=Date:To:From:Subject:Message-Id; b=H4pljTcpDgVFeeHLjIUYSmQonUZlSB06csBcGZotrBiXOtuIdhEUDU+Byt0NwqW3+abDPKrMW/JZbQvzg6BekQ4uwnEtdxNPgVPtYDUGI5GBF8YqEaTsR73eiHI3I+6iXsj9GTEa2TrRH8+MWWkS9jz0RW3jD2P6JqP8/eSRbsc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=gXeBWJ5o; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="gXeBWJ5o" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B48951F000E9; Tue, 1 Sep 2026 00:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1788222273; bh=puU8C/dDowT2YzJBh8hpx5TiQLVQgTTNMfDHDFPctrY=; h=Date:To:From:Subject; b=gXeBWJ5ou1W4WVaanWMbqdHBq5DGWbmluhKa36EBmJhiFgdaiu3DItnd9fqiZ7n4W 5+/yA+C7Ma0ywS3W1tUeJq/PjRh1atihsdqaSU+XaIEmFet3zal4axOcaWriXVcEex Ixe1kconu6JOuOuewD7WYF5E/+VW3k/wHzPocxtQ= Date: Mon, 31 Aug 2026 17:24:33 -0700 To: mm-commits@vger.kernel.org,ziy@nvidia.com,usama.arif@linux.dev,ryan.roberts@arm.com,ljs@kernel.org,liam@infradead.org,lance.yang@linux.dev,kasong@tencent.com,hughd@google.com,hannes@cmpxchg.org,dev.jain@arm.com,david@kernel.org,baolin.wang@linux.alibaba.com,baohua@kernel.org,balbirs@nvidia.com,kas@kernel.org,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-huge_memory-dequeue-the-deferred-split-after-the-split-freeze.patch added to mm-new branch Message-Id: <20260901002433.B48951F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/huge_memory: dequeue the deferred split after the split freeze has been added to the -mm mm-new branch. Its filename is mm-huge_memory-dequeue-the-deferred-split-after-the-split-freeze.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-huge_memory-dequeue-the-deferred-split-after-the-split-freeze.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next If a few days of testing in mm-new is successful, the patch will me moved into mm.git's mm-unstable branch, which is included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: "Kiryl Shutsemau (Meta)" Subject: mm/huge_memory: dequeue the deferred split after the split freeze Date: Mon, 31 Aug 2026 10:15:14 +0100 __folio_freeze_and_split_unmapped() takes the deferred split list_lru lock across the freeze. It is only there to stop deferred_split_scan() from touching the folio under split. With deferred_split_isolate() fixed, the workaround can be dropped. Unqueue the folio after folio_ref_freeze(), the way __folio_migrate_mapping() does: folio_unqueue_deferred_split() needs a zero refcount and a memcg still set, and both hold there. If the split is called from deferred_split_scan(), the unqueue is a no-op -- the folio is already removed from the list. But PG_partially_mapped is still set, so it has to be cleared here or MTHP_STAT_NR_ANON_PARTIALLY_MAPPED never comes back down. Assisted-by: Claude-Code:claude-opus-5 Link: https://lore.kernel.org/20260831091514.1879786-3-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Zi Yan Reviewed-by: Johannes Weiner Acked-by: David Hildenbrand (Arm) Reviewed-by: Lance Yang Cc: Balbir Singh Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Kairui Song Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Cc: Usama Arif Signed-off-by: Andrew Morton --- mm/huge_memory.c | 46 +++++++++++++-------------------------------- 1 file changed, 14 insertions(+), 32 deletions(-) --- a/mm/huge_memory.c~mm-huge_memory-dequeue-the-deferred-split-after-the-split-freeze +++ a/mm/huge_memory.c @@ -3979,41 +3979,27 @@ static int __folio_freeze_and_split_unma struct folio *end_folio = folio_next(folio); struct folio *new_folio, *next; int old_order = folio_order(folio); - struct list_lru_one *lru; - bool dequeue_deferred; int ret = 0; VM_WARN_ON_ONCE(!mapping && end); - /* - * If this folio can be on the deferred split queue, lock out - * the shrinker before freezing the ref. If the shrinker sees - * a 0-ref folio, it assumes it beat folio_put() to the list - * lock and must clean up the LRU state - the same dequeue we - * will do below as part of the split. - */ - dequeue_deferred = folio_test_anon(folio) && old_order > 1; - if (dequeue_deferred) { - struct mem_cgroup *memcg; - - rcu_read_lock(); - memcg = folio_memcg(folio); - lru = list_lru_lock(&deferred_split_lru, - folio_nid(folio), &memcg); - } + if (folio_ref_freeze(folio, folio_cache_ref_count(folio) + 1)) { struct swap_cluster_info *ci = NULL; struct lruvec *lruvec; - if (dequeue_deferred) { - __list_lru_del(&deferred_split_lru, lru, - &folio->_deferred_list, folio_nid(folio)); - if (folio_test_partially_mapped(folio)) { - folio_clear_partially_mapped(folio); - mod_mthp_stat(old_order, - MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, -1); - } - list_lru_unlock(lru); - rcu_read_unlock(); + /* Take off the deferred split queue while frozen and memcg set */ + folio_unqueue_deferred_split(folio); + + /* + * deferred_split_scan() takes the folio off the queue before it + * splits it, so the unqueue above finds an empty list and + * leaves PG_partially_mapped set. + * Clear it here: the flag does not survive the split. + */ + if (folio_test_partially_mapped(folio)) { + folio_clear_partially_mapped(folio); + mod_mthp_stat(old_order, + MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, -1); } if (mapping) { @@ -4115,10 +4101,6 @@ static int __folio_freeze_and_split_unma if (ci) swap_cluster_unlock(ci); } else { - if (dequeue_deferred) { - list_lru_unlock(lru); - rcu_read_unlock(); - } return -EAGAIN; } _ Patches currently in -mm which might be from kas@kernel.org are maintainers-add-myself-as-a-thp-reviewer.patch mm-huge_memory-do-not-touch-frozen-folios-in-deferred_split_isolate.patch mm-huge_memory-dequeue-the-deferred-split-after-the-split-freeze.patch