* [PATCH v3 0/2] __folio_split() clean up.
@ 2025-07-14 17:18 Zi Yan
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Zi Yan @ 2025-07-14 17:18 UTC (permalink / raw)
To: Balbir Singh, David Hildenbrand, linux-mm
Cc: Andrew Morton, Hugh Dickins, Kirill Shutemov, Lorenzo Stoakes,
Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, linux-kernel
Based on the prior discussion[1], this patch improves
__split_unmapped_folio() by making it reusable for splitting unmapped
folios. This helps avoid the need for a new boolean unmapped parameter
to guard mapping-related code.
An additional benefit is that __split_unmapped_folio() could be
called on after-split folios by __folio_split(). It can enable new split
methods. For example, at deferred split time, unmapped subpages can
scatter arbitrarily within a large folio, neither uniform nor non-uniform
split can maximize after-split folio orders for mapped subpages.
The hope is that by calling __split_unmapped_folio() multiple times,
a better split result can be achieved.
It passed mm selftests.
Changelog
===
From V2[3]:
1. Code format fixes
2. Restructured code to remove after_split goto label.
From V1[2]:
1. Fixed indentations.
2. Used folio_expected_ref_count() to calculate ref_count instead of
open coding.
[1] https://lore.kernel.org/linux-mm/94D8C1A4-780C-4BEC-A336-7D3613B54845@nvidia.com/
[2] https://lore.kernel.org/linux-mm/20250711030259.3574392-1-ziy@nvidia.com/
[2] https://lore.kernel.org/linux-mm/20250711182355.3592618-1-ziy@nvidia.com/
Zi Yan (2):
mm/huge_memory: move unrelated code out of __split_unmapped_folio()
mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
mm/huge_memory.c | 289 +++++++++++++++++++++++------------------------
1 file changed, 142 insertions(+), 147 deletions(-)
--
2.47.2
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-14 17:18 [PATCH v3 0/2] __folio_split() clean up Zi Yan
@ 2025-07-14 17:18 ` Zi Yan
2025-07-14 18:54 ` David Hildenbrand
2025-07-17 14:07 ` Lorenzo Stoakes
2025-07-14 17:18 ` [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count Zi Yan
2025-07-17 12:40 ` [PATCH v3 0/2] __folio_split() clean up Lorenzo Stoakes
2 siblings, 2 replies; 15+ messages in thread
From: Zi Yan @ 2025-07-14 17:18 UTC (permalink / raw)
To: Balbir Singh, David Hildenbrand, linux-mm
Cc: Andrew Morton, Hugh Dickins, Kirill Shutemov, Lorenzo Stoakes,
Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, linux-kernel
remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
splitting unmapped folio operations. Move them out to the caller so that
__split_unmapped_folio() only handles unmapped folio splits. This makes
__split_unmapped_folio() reusable.
Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
Signed-off-by: Zi Yan <ziy@nvidia.com>
Acked-by: Balbir Singh <balbirs@nvidia.com>
---
mm/huge_memory.c | 291 +++++++++++++++++++++++------------------------
1 file changed, 144 insertions(+), 147 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 3eb1c34be601..a7ee731f974f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3396,10 +3396,6 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
* order - 1 to new_order).
* @split_at: in buddy allocator like split, the folio containing @split_at
* will be split until its order becomes @new_order.
- * @lock_at: the folio containing @lock_at is left locked for caller.
- * @list: the after split folios will be added to @list if it is not NULL,
- * otherwise to LRU lists.
- * @end: the end of the file @folio maps to. -1 if @folio is anonymous memory.
* @xas: xa_state pointing to folio->mapping->i_pages and locked by caller
* @mapping: @folio->mapping
* @uniform_split: if the split is uniform or not (buddy allocator like split)
@@ -3425,52 +3421,26 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
* @page, which is split in next for loop.
*
* After splitting, the caller's folio reference will be transferred to the
- * folio containing @page. The other folios may be freed if they are not mapped.
- *
- * In terms of locking, after splitting,
- * 1. uniform split leaves @page (or the folio contains it) locked;
- * 2. buddy allocator like (non-uniform) split leaves @folio locked.
- *
+ * folio containing @page. The caller needs to unlock and/or free after-split
+ * folios if necessary.
*
* For !uniform_split, when -ENOMEM is returned, the original folio might be
* split. The caller needs to check the input folio.
*/
static int __split_unmapped_folio(struct folio *folio, int new_order,
- struct page *split_at, struct page *lock_at,
- struct list_head *list, pgoff_t end,
- struct xa_state *xas, struct address_space *mapping,
- bool uniform_split)
+ struct page *split_at, struct xa_state *xas,
+ struct address_space *mapping, bool uniform_split)
{
- struct lruvec *lruvec;
- struct address_space *swap_cache = NULL;
- struct folio *origin_folio = folio;
- struct folio *next_folio = folio_next(folio);
- struct folio *new_folio;
struct folio *next;
int order = folio_order(folio);
int split_order;
int start_order = uniform_split ? new_order : order - 1;
- int nr_dropped = 0;
int ret = 0;
bool stop_split = false;
- if (folio_test_swapcache(folio)) {
- VM_BUG_ON(mapping);
-
- /* a swapcache folio can only be uniformly split to order-0 */
- if (!uniform_split || new_order != 0)
- return -EINVAL;
-
- swap_cache = swap_address_space(folio->swap);
- xa_lock(&swap_cache->i_pages);
- }
-
if (folio_test_anon(folio))
mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
- /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
- lruvec = folio_lruvec_lock(folio);
-
folio_clear_has_hwpoisoned(folio);
/*
@@ -3480,9 +3450,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
for (split_order = start_order;
split_order >= new_order && !stop_split;
split_order--) {
- int old_order = folio_order(folio);
- struct folio *release;
struct folio *end_folio = folio_next(folio);
+ int old_order = folio_order(folio);
+ struct folio *new_folio;
/* order-1 anonymous folio is not supported */
if (folio_test_anon(folio) && split_order == 1)
@@ -3504,126 +3474,44 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
if (xas_error(xas)) {
ret = xas_error(xas);
stop_split = true;
- goto after_split;
}
}
}
- folio_split_memcg_refs(folio, old_order, split_order);
- split_page_owner(&folio->page, old_order, split_order);
- pgalloc_tag_split(folio, old_order, split_order);
-
- __split_folio_to_order(folio, old_order, split_order);
+ if (!stop_split) {
+ folio_split_memcg_refs(folio, old_order, split_order);
+ split_page_owner(&folio->page, old_order, split_order);
+ pgalloc_tag_split(folio, old_order, split_order);
-after_split:
+ __split_folio_to_order(folio, old_order, split_order);
+ }
/*
- * Iterate through after-split folios and perform related
- * operations. But in buddy allocator like split, the folio
+ * Iterate through after-split folios and update folio stats.
+ * But in buddy allocator like split, the folio
* containing the specified page is skipped until its order
* is new_order, since the folio will be worked on in next
* iteration.
*/
- for (release = folio; release != end_folio; release = next) {
- next = folio_next(release);
+ for (new_folio = folio; new_folio != end_folio; new_folio = next) {
+ next = folio_next(new_folio);
/*
- * for buddy allocator like split, the folio containing
- * page will be split next and should not be released,
- * until the folio's order is new_order or stop_split
- * is set to true by the above xas_split() failure.
+ * for buddy allocator like split, new_folio containing
+ * page could be split again, thus do not change stats
+ * yet. Wait until new_folio's order is new_order or
+ * stop_split is set to true by the above xas_split()
+ * failure.
*/
- if (release == page_folio(split_at)) {
- folio = release;
+ if (new_folio == page_folio(split_at)) {
+ folio = new_folio;
if (split_order != new_order && !stop_split)
continue;
}
- if (folio_test_anon(release)) {
- mod_mthp_stat(folio_order(release),
- MTHP_STAT_NR_ANON, 1);
- }
-
- /*
- * origin_folio should be kept frozon until page cache
- * entries are updated with all the other after-split
- * folios to prevent others seeing stale page cache
- * entries.
- */
- if (release == origin_folio)
- continue;
-
- folio_ref_unfreeze(release, 1 +
- ((mapping || swap_cache) ?
- folio_nr_pages(release) : 0));
-
- lru_add_split_folio(origin_folio, release, lruvec,
- list);
-
- /* Some pages can be beyond EOF: drop them from cache */
- if (release->index >= end) {
- if (shmem_mapping(mapping))
- nr_dropped += folio_nr_pages(release);
- else if (folio_test_clear_dirty(release))
- folio_account_cleaned(release,
- inode_to_wb(mapping->host));
- __filemap_remove_folio(release, NULL);
- folio_put_refs(release, folio_nr_pages(release));
- } else if (mapping) {
- __xa_store(&mapping->i_pages,
- release->index, release, 0);
- } else if (swap_cache) {
- __xa_store(&swap_cache->i_pages,
- swap_cache_index(release->swap),
- release, 0);
- }
+ if (folio_test_anon(new_folio))
+ mod_mthp_stat(folio_order(new_folio),
+ MTHP_STAT_NR_ANON, 1);
}
}
- /*
- * Unfreeze origin_folio only after all page cache entries, which used
- * to point to it, have been updated with new folios. Otherwise,
- * a parallel folio_try_get() can grab origin_folio and its caller can
- * see stale page cache entries.
- */
- folio_ref_unfreeze(origin_folio, 1 +
- ((mapping || swap_cache) ? folio_nr_pages(origin_folio) : 0));
-
- unlock_page_lruvec(lruvec);
-
- if (swap_cache)
- xa_unlock(&swap_cache->i_pages);
- if (mapping)
- xa_unlock(&mapping->i_pages);
-
- /* Caller disabled irqs, so they are still disabled here */
- local_irq_enable();
-
- if (nr_dropped)
- shmem_uncharge(mapping->host, nr_dropped);
-
- remap_page(origin_folio, 1 << order,
- folio_test_anon(origin_folio) ?
- RMP_USE_SHARED_ZEROPAGE : 0);
-
- /*
- * At this point, folio should contain the specified page.
- * For uniform split, it is left for caller to unlock.
- * For buddy allocator like split, the first after-split folio is left
- * for caller to unlock.
- */
- for (new_folio = origin_folio; new_folio != next_folio; new_folio = next) {
- next = folio_next(new_folio);
- if (new_folio == page_folio(lock_at))
- continue;
-
- folio_unlock(new_folio);
- /*
- * Subpages may be freed if there wasn't any mapping
- * like if add_to_swap() is running on a lru page that
- * had its mapping zapped. And freeing these pages
- * requires taking the lru_lock so we do the put_page
- * of the tail pages after the split is complete.
- */
- free_folio_and_swap_cache(new_folio);
- }
return ret;
}
@@ -3706,10 +3594,13 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
{
struct deferred_split *ds_queue = get_deferred_split_queue(folio);
XA_STATE(xas, &folio->mapping->i_pages, folio->index);
+ struct folio *next_folio = folio_next(folio);
bool is_anon = folio_test_anon(folio);
struct address_space *mapping = NULL;
struct anon_vma *anon_vma = NULL;
int order = folio_order(folio);
+ struct folio *new_folio, *next;
+ int nr_shmem_dropped = 0;
int extra_pins, ret;
pgoff_t end;
bool is_hzp;
@@ -3833,13 +3724,18 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
*/
xas_lock(&xas);
xas_reset(&xas);
- if (xas_load(&xas) != folio)
+ if (xas_load(&xas) != folio) {
+ ret = -EAGAIN;
goto fail;
+ }
}
/* Prevent deferred_split_scan() touching ->_refcount */
spin_lock(&ds_queue->split_queue_lock);
if (folio_ref_freeze(folio, 1 + extra_pins)) {
+ struct address_space *swap_cache = NULL;
+ struct lruvec *lruvec;
+
if (folio_order(folio) > 1 &&
!list_empty(&folio->_deferred_list)) {
ds_queue->split_queue_len--;
@@ -3873,18 +3769,119 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
}
}
- ret = __split_unmapped_folio(folio, new_order,
- split_at, lock_at, list, end, &xas, mapping,
- uniform_split);
+ if (folio_test_swapcache(folio)) {
+ if (mapping) {
+ VM_WARN_ON_ONCE_FOLIO(mapping, folio);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /*
+ * a swapcache folio can only be uniformly split to
+ * order-0
+ */
+ if (!uniform_split || new_order != 0) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ swap_cache = swap_address_space(folio->swap);
+ xa_lock(&swap_cache->i_pages);
+ }
+
+ /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
+ lruvec = folio_lruvec_lock(folio);
+
+ ret = __split_unmapped_folio(folio, new_order, split_at, &xas,
+ mapping, uniform_split);
+
+ /*
+ * Unfreeze after-split folios and put them back to the right
+ * list. @folio should be kept frozon until page cache entries
+ * are updated with all the other after-split folios to prevent
+ * others seeing stale page cache entries.
+ */
+ for (new_folio = folio_next(folio); new_folio != next_folio;
+ new_folio = next) {
+ next = folio_next(new_folio);
+
+ folio_ref_unfreeze(
+ new_folio,
+ 1 + ((mapping || swap_cache) ?
+ folio_nr_pages(new_folio) :
+ 0));
+
+ lru_add_split_folio(folio, new_folio, lruvec, list);
+
+ /* Some pages can be beyond EOF: drop them from cache */
+ if (new_folio->index >= end) {
+ if (shmem_mapping(mapping))
+ nr_shmem_dropped += folio_nr_pages(new_folio);
+ else if (folio_test_clear_dirty(new_folio))
+ folio_account_cleaned(
+ new_folio,
+ inode_to_wb(mapping->host));
+ __filemap_remove_folio(new_folio, NULL);
+ folio_put_refs(new_folio,
+ folio_nr_pages(new_folio));
+ } else if (mapping) {
+ __xa_store(&mapping->i_pages, new_folio->index,
+ new_folio, 0);
+ } else if (swap_cache) {
+ __xa_store(&swap_cache->i_pages,
+ swap_cache_index(new_folio->swap),
+ new_folio, 0);
+ }
+ }
+ /*
+ * Unfreeze @folio only after all page cache entries, which
+ * used to point to it, have been updated with new folios.
+ * Otherwise, a parallel folio_try_get() can grab origin_folio
+ * and its caller can see stale page cache entries.
+ */
+ folio_ref_unfreeze(folio, 1 +
+ ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
+
+ unlock_page_lruvec(lruvec);
+
+ if (swap_cache)
+ xa_unlock(&swap_cache->i_pages);
} else {
spin_unlock(&ds_queue->split_queue_lock);
-fail:
- if (mapping)
- xas_unlock(&xas);
- local_irq_enable();
- remap_page(folio, folio_nr_pages(folio), 0);
ret = -EAGAIN;
}
+fail:
+ if (mapping)
+ xas_unlock(&xas);
+
+ local_irq_enable();
+
+ if (nr_shmem_dropped)
+ shmem_uncharge(mapping->host, nr_shmem_dropped);
+
+ remap_page(folio, 1 << order,
+ !ret && folio_test_anon(folio) ? RMP_USE_SHARED_ZEROPAGE :
+ 0);
+
+ /*
+ * Unlock all after-split folios except the one containing @lock_at
+ * page. If @folio is not split, it will be kept locked.
+ */
+ for (new_folio = folio; new_folio != next_folio; new_folio = next) {
+ next = folio_next(new_folio);
+ if (new_folio == page_folio(lock_at))
+ continue;
+
+ folio_unlock(new_folio);
+ /*
+ * Subpages may be freed if there wasn't any mapping
+ * like if add_to_swap() is running on a lru page that
+ * had its mapping zapped. And freeing these pages
+ * requires taking the lru_lock so we do the put_page
+ * of the tail pages after the split is complete.
+ */
+ free_folio_and_swap_cache(new_folio);
+ }
out_unlock:
if (anon_vma) {
--
2.47.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
2025-07-14 17:18 [PATCH v3 0/2] __folio_split() clean up Zi Yan
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
@ 2025-07-14 17:18 ` Zi Yan
2025-07-17 8:03 ` Baolin Wang
2025-07-17 14:31 ` Lorenzo Stoakes
2025-07-17 12:40 ` [PATCH v3 0/2] __folio_split() clean up Lorenzo Stoakes
2 siblings, 2 replies; 15+ messages in thread
From: Zi Yan @ 2025-07-14 17:18 UTC (permalink / raw)
To: Balbir Singh, David Hildenbrand, linux-mm
Cc: Andrew Morton, Hugh Dickins, Kirill Shutemov, Lorenzo Stoakes,
Zi Yan, Baolin Wang, Liam R. Howlett, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, linux-kernel
Instead of open coding the ref_count calculation, use
folio_expected_ref_count().
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Zi Yan <ziy@nvidia.com>
Acked-by: Balbir Singh <balbirs@nvidia.com>
Acked-by: David Hildenbrand <david@redhat.com>
---
mm/huge_memory.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a7ee731f974f..31b5c4e61a57 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3735,6 +3735,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
if (folio_ref_freeze(folio, 1 + extra_pins)) {
struct address_space *swap_cache = NULL;
struct lruvec *lruvec;
+ int expected_refs;
if (folio_order(folio) > 1 &&
!list_empty(&folio->_deferred_list)) {
@@ -3805,11 +3806,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
new_folio = next) {
next = folio_next(new_folio);
- folio_ref_unfreeze(
- new_folio,
- 1 + ((mapping || swap_cache) ?
- folio_nr_pages(new_folio) :
- 0));
+ expected_refs = folio_expected_ref_count(new_folio) + 1;
+ folio_ref_unfreeze(new_folio, expected_refs);
lru_add_split_folio(folio, new_folio, lruvec, list);
@@ -3839,8 +3837,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
* Otherwise, a parallel folio_try_get() can grab origin_folio
* and its caller can see stale page cache entries.
*/
- folio_ref_unfreeze(folio, 1 +
- ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
+ expected_refs = folio_expected_ref_count(folio) + 1;
+ folio_ref_unfreeze(folio, expected_refs);
unlock_page_lruvec(lruvec);
--
2.47.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
@ 2025-07-14 18:54 ` David Hildenbrand
2025-07-17 14:07 ` Lorenzo Stoakes
1 sibling, 0 replies; 15+ messages in thread
From: David Hildenbrand @ 2025-07-14 18:54 UTC (permalink / raw)
To: Zi Yan, Balbir Singh, linux-mm
Cc: Andrew Morton, Hugh Dickins, Kirill Shutemov, Lorenzo Stoakes,
Baolin Wang, Liam R. Howlett, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, linux-kernel
On 14.07.25 19:18, Zi Yan wrote:
> remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
> splitting unmapped folio operations. Move them out to the caller so that
> __split_unmapped_folio() only handles unmapped folio splits. This makes
> __split_unmapped_folio() reusable.
>
> Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Balbir Singh <balbirs@nvidia.com>
> ---
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
2025-07-14 17:18 ` [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count Zi Yan
@ 2025-07-17 8:03 ` Baolin Wang
2025-07-17 14:31 ` Lorenzo Stoakes
1 sibling, 0 replies; 15+ messages in thread
From: Baolin Wang @ 2025-07-17 8:03 UTC (permalink / raw)
To: Zi Yan, Balbir Singh, David Hildenbrand, linux-mm
Cc: Andrew Morton, Hugh Dickins, Kirill Shutemov, Lorenzo Stoakes,
Liam R. Howlett, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
linux-kernel
On 2025/7/15 01:18, Zi Yan wrote:
> Instead of open coding the ref_count calculation, use
> folio_expected_ref_count().
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Balbir Singh <balbirs@nvidia.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> ---
Looks more readable. Thanks.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> mm/huge_memory.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index a7ee731f974f..31b5c4e61a57 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3735,6 +3735,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> if (folio_ref_freeze(folio, 1 + extra_pins)) {
> struct address_space *swap_cache = NULL;
> struct lruvec *lruvec;
> + int expected_refs;
>
> if (folio_order(folio) > 1 &&
> !list_empty(&folio->_deferred_list)) {
> @@ -3805,11 +3806,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> new_folio = next) {
> next = folio_next(new_folio);
>
> - folio_ref_unfreeze(
> - new_folio,
> - 1 + ((mapping || swap_cache) ?
> - folio_nr_pages(new_folio) :
> - 0));
> + expected_refs = folio_expected_ref_count(new_folio) + 1;
> + folio_ref_unfreeze(new_folio, expected_refs);
>
> lru_add_split_folio(folio, new_folio, lruvec, list);
>
> @@ -3839,8 +3837,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> * Otherwise, a parallel folio_try_get() can grab origin_folio
> * and its caller can see stale page cache entries.
> */
> - folio_ref_unfreeze(folio, 1 +
> - ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
> + expected_refs = folio_expected_ref_count(folio) + 1;
> + folio_ref_unfreeze(folio, expected_refs);
>
> unlock_page_lruvec(lruvec);
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 0/2] __folio_split() clean up.
2025-07-14 17:18 [PATCH v3 0/2] __folio_split() clean up Zi Yan
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
2025-07-14 17:18 ` [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count Zi Yan
@ 2025-07-17 12:40 ` Lorenzo Stoakes
2025-07-17 15:54 ` Zi Yan
2025-07-17 22:35 ` Andrew Morton
2 siblings, 2 replies; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 12:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Balbir Singh, Zi Yan, David Hildenbrand, linux-mm, Hugh Dickins,
Kirill Shutemov, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, linux-kernel
Hm something has gone weird in mm-new with this.
The patches are in the correct order, but the 2/2 patch, 'mm/huge_memory: use
folio_expected_ref_count() to calculate ref_count.' contains the cover letter
and has the suffix:
This patch (of 2):
Instead of open coding the ref_count calculation, use
folio_expected_ref_count()
But immediately prior to it is 1/2 - mm/huge_memory: move unrelated code
out of __split_unmapped_folio() but with no cover letter reference.
Andrew - has quilt got confused here? :)
Thanks, Lorenzo
On Mon, Jul 14, 2025 at 01:18:21PM -0400, Zi Yan wrote:
> Based on the prior discussion[1], this patch improves
> __split_unmapped_folio() by making it reusable for splitting unmapped
> folios. This helps avoid the need for a new boolean unmapped parameter
> to guard mapping-related code.
>
> An additional benefit is that __split_unmapped_folio() could be
> called on after-split folios by __folio_split(). It can enable new split
> methods. For example, at deferred split time, unmapped subpages can
> scatter arbitrarily within a large folio, neither uniform nor non-uniform
> split can maximize after-split folio orders for mapped subpages.
> The hope is that by calling __split_unmapped_folio() multiple times,
> a better split result can be achieved.
>
> It passed mm selftests.
>
>
> Changelog
> ===
> From V2[3]:
> 1. Code format fixes
> 2. Restructured code to remove after_split goto label.
>
> From V1[2]:
> 1. Fixed indentations.
> 2. Used folio_expected_ref_count() to calculate ref_count instead of
> open coding.
>
>
> [1] https://lore.kernel.org/linux-mm/94D8C1A4-780C-4BEC-A336-7D3613B54845@nvidia.com/
> [2] https://lore.kernel.org/linux-mm/20250711030259.3574392-1-ziy@nvidia.com/
> [2] https://lore.kernel.org/linux-mm/20250711182355.3592618-1-ziy@nvidia.com/
>
> Zi Yan (2):
> mm/huge_memory: move unrelated code out of __split_unmapped_folio()
> mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
>
> mm/huge_memory.c | 289 +++++++++++++++++++++++------------------------
> 1 file changed, 142 insertions(+), 147 deletions(-)
>
> --
> 2.47.2
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
2025-07-14 18:54 ` David Hildenbrand
@ 2025-07-17 14:07 ` Lorenzo Stoakes
2025-07-17 15:41 ` Zi Yan
1 sibling, 1 reply; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 14:07 UTC (permalink / raw)
To: Zi Yan
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Mon, Jul 14, 2025 at 01:18:22PM -0400, Zi Yan wrote:
> remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
> splitting unmapped folio operations. Move them out to the caller so that
> __split_unmapped_folio() only handles unmapped folio splits. This makes
> __split_unmapped_folio() reusable.
Nit but maybe worth mentioning the various renames etc.
>
> Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Balbir Singh <balbirs@nvidia.com>
After a lot of staring, 2 difftastic's at once and exactly 0 coverity
instances, I've convinced myself this looks right.
I think you really should have split this up into smaller patches, as this
is moving stuff around and changing stuff all at once with a lot of
complexity and moving parts.
However not going to make you do that, since you got acks and I don't want
to hold this up.
I have a few nits + queries below that need addressing however, see below.
> ---
> mm/huge_memory.c | 291 +++++++++++++++++++++++------------------------
> 1 file changed, 144 insertions(+), 147 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 3eb1c34be601..a7ee731f974f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3396,10 +3396,6 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
> * order - 1 to new_order).
> * @split_at: in buddy allocator like split, the folio containing @split_at
> * will be split until its order becomes @new_order.
> - * @lock_at: the folio containing @lock_at is left locked for caller.
> - * @list: the after split folios will be added to @list if it is not NULL,
> - * otherwise to LRU lists.
> - * @end: the end of the file @folio maps to. -1 if @folio is anonymous memory.
> * @xas: xa_state pointing to folio->mapping->i_pages and locked by caller
> * @mapping: @folio->mapping
> * @uniform_split: if the split is uniform or not (buddy allocator like split)
> @@ -3425,52 +3421,26 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
> * @page, which is split in next for loop.
> *
> * After splitting, the caller's folio reference will be transferred to the
> - * folio containing @page. The other folios may be freed if they are not mapped.
> - *
> - * In terms of locking, after splitting,
> - * 1. uniform split leaves @page (or the folio contains it) locked;
> - * 2. buddy allocator like (non-uniform) split leaves @folio locked.
Are these no longer relevant? Shouldn't we retain this, or move it
elsewhere if appropriate?
> - *
> + * folio containing @page. The caller needs to unlock and/or free after-split
> + * folios if necessary.
> *
> * For !uniform_split, when -ENOMEM is returned, the original folio might be
> * split. The caller needs to check the input folio.
> */
> static int __split_unmapped_folio(struct folio *folio, int new_order,
> - struct page *split_at, struct page *lock_at,
> - struct list_head *list, pgoff_t end,
> - struct xa_state *xas, struct address_space *mapping,
> - bool uniform_split)
> + struct page *split_at, struct xa_state *xas,
> + struct address_space *mapping, bool uniform_split)
> {
> - struct lruvec *lruvec;
> - struct address_space *swap_cache = NULL;
> - struct folio *origin_folio = folio;
> - struct folio *next_folio = folio_next(folio);
> - struct folio *new_folio;
> struct folio *next;
> int order = folio_order(folio);
> int split_order;
> int start_order = uniform_split ? new_order : order - 1;
> - int nr_dropped = 0;
> int ret = 0;
> bool stop_split = false;
>
> - if (folio_test_swapcache(folio)) {
> - VM_BUG_ON(mapping);
Good to get rid of this.
> -
> - /* a swapcache folio can only be uniformly split to order-0 */
> - if (!uniform_split || new_order != 0)
> - return -EINVAL;
> -
> - swap_cache = swap_address_space(folio->swap);
> - xa_lock(&swap_cache->i_pages);
> - }
> -
> if (folio_test_anon(folio))
> mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
>
> - /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
> - lruvec = folio_lruvec_lock(folio);
> -
> folio_clear_has_hwpoisoned(folio);
>
> /*
> @@ -3480,9 +3450,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
> for (split_order = start_order;
> split_order >= new_order && !stop_split;
> split_order--) {
> - int old_order = folio_order(folio);
> - struct folio *release;
> struct folio *end_folio = folio_next(folio);
> + int old_order = folio_order(folio);
> + struct folio *new_folio;
>
> /* order-1 anonymous folio is not supported */
> if (folio_test_anon(folio) && split_order == 1)
> @@ -3504,126 +3474,44 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
> if (xas_error(xas)) {
> ret = xas_error(xas);
> stop_split = true;
> - goto after_split;
> }
> }
> }
>
> - folio_split_memcg_refs(folio, old_order, split_order);
> - split_page_owner(&folio->page, old_order, split_order);
> - pgalloc_tag_split(folio, old_order, split_order);
> -
> - __split_folio_to_order(folio, old_order, split_order);
> + if (!stop_split) {
> + folio_split_memcg_refs(folio, old_order, split_order);
> + split_page_owner(&folio->page, old_order, split_order);
> + pgalloc_tag_split(folio, old_order, split_order);
>
> -after_split:
> + __split_folio_to_order(folio, old_order, split_order);
> + }
> /*
> - * Iterate through after-split folios and perform related
> - * operations. But in buddy allocator like split, the folio
> + * Iterate through after-split folios and update folio stats.
Good to spell out what the 'related operations' are :) Of course you're
changing this so this loop does some and the other loop does the post-split
rest.
> + * But in buddy allocator like split, the folio
> * containing the specified page is skipped until its order
> * is new_order, since the folio will be worked on in next
> * iteration.
> */
> - for (release = folio; release != end_folio; release = next) {
> - next = folio_next(release);
> + for (new_folio = folio; new_folio != end_folio; new_folio = next) {
> + next = folio_next(new_folio);
> /*
> - * for buddy allocator like split, the folio containing
> - * page will be split next and should not be released,
> - * until the folio's order is new_order or stop_split
> - * is set to true by the above xas_split() failure.
> + * for buddy allocator like split, new_folio containing
> + * page could be split again, thus do not change stats
> + * yet. Wait until new_folio's order is new_order or
> + * stop_split is set to true by the above xas_split()
> + * failure.
> */
> - if (release == page_folio(split_at)) {
> - folio = release;
> + if (new_folio == page_folio(split_at)) {
> + folio = new_folio;
> if (split_order != new_order && !stop_split)
> continue;
> }
> - if (folio_test_anon(release)) {
> - mod_mthp_stat(folio_order(release),
> - MTHP_STAT_NR_ANON, 1);
> - }
> -
> - /*
> - * origin_folio should be kept frozon until page cache
> - * entries are updated with all the other after-split
> - * folios to prevent others seeing stale page cache
> - * entries.
> - */
> - if (release == origin_folio)
> - continue;
> -
> - folio_ref_unfreeze(release, 1 +
> - ((mapping || swap_cache) ?
> - folio_nr_pages(release) : 0));
> -
> - lru_add_split_folio(origin_folio, release, lruvec,
> - list);
> -
> - /* Some pages can be beyond EOF: drop them from cache */
> - if (release->index >= end) {
> - if (shmem_mapping(mapping))
> - nr_dropped += folio_nr_pages(release);
> - else if (folio_test_clear_dirty(release))
> - folio_account_cleaned(release,
> - inode_to_wb(mapping->host));
> - __filemap_remove_folio(release, NULL);
> - folio_put_refs(release, folio_nr_pages(release));
> - } else if (mapping) {
> - __xa_store(&mapping->i_pages,
> - release->index, release, 0);
> - } else if (swap_cache) {
> - __xa_store(&swap_cache->i_pages,
> - swap_cache_index(release->swap),
> - release, 0);
> - }
> + if (folio_test_anon(new_folio))
> + mod_mthp_stat(folio_order(new_folio),
> + MTHP_STAT_NR_ANON, 1);
> }
> }
>
> - /*
> - * Unfreeze origin_folio only after all page cache entries, which used
> - * to point to it, have been updated with new folios. Otherwise,
> - * a parallel folio_try_get() can grab origin_folio and its caller can
> - * see stale page cache entries.
> - */
> - folio_ref_unfreeze(origin_folio, 1 +
> - ((mapping || swap_cache) ? folio_nr_pages(origin_folio) : 0));
> -
> - unlock_page_lruvec(lruvec);
> -
> - if (swap_cache)
> - xa_unlock(&swap_cache->i_pages);
> - if (mapping)
> - xa_unlock(&mapping->i_pages);
> -
> - /* Caller disabled irqs, so they are still disabled here */
> - local_irq_enable();
> -
> - if (nr_dropped)
> - shmem_uncharge(mapping->host, nr_dropped);
> -
> - remap_page(origin_folio, 1 << order,
> - folio_test_anon(origin_folio) ?
> - RMP_USE_SHARED_ZEROPAGE : 0);
> -
> - /*
> - * At this point, folio should contain the specified page.
> - * For uniform split, it is left for caller to unlock.
> - * For buddy allocator like split, the first after-split folio is left
> - * for caller to unlock.
> - */
> - for (new_folio = origin_folio; new_folio != next_folio; new_folio = next) {
> - next = folio_next(new_folio);
> - if (new_folio == page_folio(lock_at))
> - continue;
> -
> - folio_unlock(new_folio);
> - /*
> - * Subpages may be freed if there wasn't any mapping
> - * like if add_to_swap() is running on a lru page that
> - * had its mapping zapped. And freeing these pages
> - * requires taking the lru_lock so we do the put_page
> - * of the tail pages after the split is complete.
> - */
> - free_folio_and_swap_cache(new_folio);
> - }
> return ret;
> }
>
> @@ -3706,10 +3594,13 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> {
> struct deferred_split *ds_queue = get_deferred_split_queue(folio);
> XA_STATE(xas, &folio->mapping->i_pages, folio->index);
> + struct folio *next_folio = folio_next(folio);
> bool is_anon = folio_test_anon(folio);
> struct address_space *mapping = NULL;
> struct anon_vma *anon_vma = NULL;
> int order = folio_order(folio);
> + struct folio *new_folio, *next;
> + int nr_shmem_dropped = 0;
> int extra_pins, ret;
> pgoff_t end;
> bool is_hzp;
There's some VM_BUG_ON_FOLIO()'s in the code:
VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
That should probably be VM_WARN_ON() or VM_WARN_ON_ONCE(), maybe worth
changing here too?
> @@ -3833,13 +3724,18 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> */
> xas_lock(&xas);
> xas_reset(&xas);
> - if (xas_load(&xas) != folio)
> + if (xas_load(&xas) != folio) {
> + ret = -EAGAIN;
It is beyond words that the original logic manually set ret == -EAGAIN...
And this is the only place we 'goto fail'.
Yikes this code is a horror show.
> goto fail;
> + }
> }
>
> /* Prevent deferred_split_scan() touching ->_refcount */
> spin_lock(&ds_queue->split_queue_lock);
> if (folio_ref_freeze(folio, 1 + extra_pins)) {
> + struct address_space *swap_cache = NULL;
> + struct lruvec *lruvec;
> +
> if (folio_order(folio) > 1 &&
> !list_empty(&folio->_deferred_list)) {
> ds_queue->split_queue_len--;
> @@ -3873,18 +3769,119 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> }
> }
>
> - ret = __split_unmapped_folio(folio, new_order,
> - split_at, lock_at, list, end, &xas, mapping,
> - uniform_split);
> + if (folio_test_swapcache(folio)) {
> + if (mapping) {
> + VM_WARN_ON_ONCE_FOLIO(mapping, folio);
> + ret = -EINVAL;
> + goto fail;
It's a new code path (in prod we'd just carry on, or in debug we would
haven oops'd), but I think valid.
I wonder if this is almost over-cautious, as this would require a non-anon
folio to be in the swap-cache (since the is_anon path will set mapping
NUL).
But at the same time, probably worth keeping in at least for now.
> + }
> +
> + /*
> + * a swapcache folio can only be uniformly split to
> + * order-0
> + */
> + if (!uniform_split || new_order != 0) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + swap_cache = swap_address_space(folio->swap);
> + xa_lock(&swap_cache->i_pages);
> + }
> +
> + /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
> + lruvec = folio_lruvec_lock(folio);
> +
> + ret = __split_unmapped_folio(folio, new_order, split_at, &xas,
> + mapping, uniform_split);
> +
> + /*
> + * Unfreeze after-split folios and put them back to the right
> + * list. @folio should be kept frozon until page cache entries
> + * are updated with all the other after-split folios to prevent
> + * others seeing stale page cache entries.
> + */
> + for (new_folio = folio_next(folio); new_folio != next_folio;
> + new_folio = next) {
Hm now we have 'next' and 'next_folio', this is quite confusing.
Seems to me new_folio should be end_folio no, like the original? And maybe
then rename next to next_folio? As it is kinda inconsistent that it isn't
suffixed with _folio anyway.
> + next = folio_next(new_folio);
> +
We're no longer doing what would here be new_folio == origin_folio
(previously, release == origin_folio).
Is this correct? Why do we no longer ned to do this?
Is it because __split_unmapped_folio() will somehow take care of this in
advance/render this meaningless?
This definitely needs to be mentioned in the commit message.
> + folio_ref_unfreeze(
> + new_folio,
> + 1 + ((mapping || swap_cache) ?
> + folio_nr_pages(new_folio) :
> + 0));
Again, be nice to separate this out, but I think in a follow-up not here.
> +
> + lru_add_split_folio(folio, new_folio, lruvec, list);
> +
> + /* Some pages can be beyond EOF: drop them from cache */
> + if (new_folio->index >= end) {
> + if (shmem_mapping(mapping))
> + nr_shmem_dropped += folio_nr_pages(new_folio);
> + else if (folio_test_clear_dirty(new_folio))
> + folio_account_cleaned(
> + new_folio,
> + inode_to_wb(mapping->host));
> + __filemap_remove_folio(new_folio, NULL);
> + folio_put_refs(new_folio,
> + folio_nr_pages(new_folio));
> + } else if (mapping) {
> + __xa_store(&mapping->i_pages, new_folio->index,
> + new_folio, 0);
> + } else if (swap_cache) {
> + __xa_store(&swap_cache->i_pages,
> + swap_cache_index(new_folio->swap),
> + new_folio, 0);
> + }
> + }
> + /*
> + * Unfreeze @folio only after all page cache entries, which
> + * used to point to it, have been updated with new folios.
> + * Otherwise, a parallel folio_try_get() can grab origin_folio
> + * and its caller can see stale page cache entries.
> + */
> + folio_ref_unfreeze(folio, 1 +
> + ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
This line is horrid, probably one for a future series but this sort of
calculation of what the number of refs should be post-freeze should clearly
be separated out or at least made abundantly clear in an open-coded
implementation.
> +
> + unlock_page_lruvec(lruvec);
> +
> + if (swap_cache)
> + xa_unlock(&swap_cache->i_pages);
> } else {
> spin_unlock(&ds_queue->split_queue_lock);
> -fail:
> - if (mapping)
> - xas_unlock(&xas);
> - local_irq_enable();
> - remap_page(folio, folio_nr_pages(folio), 0);
> ret = -EAGAIN;
> }
> +fail:
> + if (mapping)
> + xas_unlock(&xas);
> +
> + local_irq_enable();
> +
> + if (nr_shmem_dropped)
> + shmem_uncharge(mapping->host, nr_shmem_dropped);
> +
> + remap_page(folio, 1 << order,
> + !ret && folio_test_anon(folio) ? RMP_USE_SHARED_ZEROPAGE :
> + 0);
I really don't like this !ret but here, this isn't very readable.
Something like:
int flags;
...
if (!ret && folio_test_anon(folio))
flags = RMP_USE_SHARED_ZERO_PAGE;
remap_page(folio, 1 << order, flags);
Would be better.
But really this is all screaming out to be separated into parts of
course. But that's one for a follow-up series...
> +
> + /*
> + * Unlock all after-split folios except the one containing @lock_at
> + * page. If @folio is not split, it will be kept locked.
> + */
> + for (new_folio = folio; new_folio != next_folio; new_folio = next) {
> + next = folio_next(new_folio);
> + if (new_folio == page_folio(lock_at))
> + continue;
> +
> + folio_unlock(new_folio);
> + /*
> + * Subpages may be freed if there wasn't any mapping
> + * like if add_to_swap() is running on a lru page that
> + * had its mapping zapped. And freeing these pages
> + * requires taking the lru_lock so we do the put_page
> + * of the tail pages after the split is complete.
> + */
> + free_folio_and_swap_cache(new_folio);
> + }
>
> out_unlock:
> if (anon_vma) {
> --
> 2.47.2
>
Generally I see why you're not using origin_folio any more since you can
just use folio everywhere, but I wonder if this makes things more
confusing.
On the other hand, this function is already hugely confusing so maybe not a
big deal and can be addressed in follow ups...
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
2025-07-14 17:18 ` [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count Zi Yan
2025-07-17 8:03 ` Baolin Wang
@ 2025-07-17 14:31 ` Lorenzo Stoakes
1 sibling, 0 replies; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 14:31 UTC (permalink / raw)
To: Zi Yan
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Mon, Jul 14, 2025 at 01:18:23PM -0400, Zi Yan wrote:
> Instead of open coding the ref_count calculation, use
> folio_expected_ref_count().
You really should put something here about why it is that the open-coded
value and the value returned from folio_expected_ref_count() would be
expected to be the same. See comment below inline with code.
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Balbir Singh <balbirs@nvidia.com>
> Acked-by: David Hildenbrand <david@redhat.com>
Ah haha you're literally addresing some of my code review here from the
last patch :) I love it when that happens :P
I'd like you to improve the commit message, but that's a nit so:
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
See below for some analysis of the folio_expected_ref_count().
> ---
> mm/huge_memory.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index a7ee731f974f..31b5c4e61a57 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3735,6 +3735,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> if (folio_ref_freeze(folio, 1 + extra_pins)) {
> struct address_space *swap_cache = NULL;
> struct lruvec *lruvec;
> + int expected_refs;
>
> if (folio_order(folio) > 1 &&
> !list_empty(&folio->_deferred_list)) {
> @@ -3805,11 +3806,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> new_folio = next) {
> next = folio_next(new_folio);
>
> - folio_ref_unfreeze(
> - new_folio,
> - 1 + ((mapping || swap_cache) ?
> - folio_nr_pages(new_folio) :
> - 0));
> + expected_refs = folio_expected_ref_count(new_folio) + 1;
So digging in:
static inline int folio_expected_ref_count(const struct folio *folio)
{
const int order = folio_order(folio);
int ref_count = 0;
...
if (folio_test_anon(folio)) {
/* One reference per page from the swapcache. */
ref_count += folio_test_swapcache(folio) << order;
} else {
/* One reference per page from the pagecache. */
ref_count += !!folio->mapping << order;
^---- these are covered off by (mapping || swap_cache) ? folio_nr_pages(folio)
/* One reference from PG_private. */
ref_count += folio_test_private(folio);
This one is trickier.
OK so looking through the logic, the can_split_folio() function will
already assert that the only pins you have are the swapcache/page cache
ones on the 'origin' folio (the mapcount bit used in the freeze doesn't matter
as you're dealing with split, not-yet-mapped 'sub'-folios).
So this precludes an elevated refcount from PG_private, therefore this will
naturally be 0.
}
/* One reference per page table mapping. */
return ref_count + folio_mapcount(folio);
folio_mapcount() will be zero for these split folios, until remapped.
}
You add the + 1 to account for the folio pin of course.
TL;DR - this is correct AFAICT.
> + folio_ref_unfreeze(new_folio, expected_refs);
>
> lru_add_split_folio(folio, new_folio, lruvec, list);
>
> @@ -3839,8 +3837,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> * Otherwise, a parallel folio_try_get() can grab origin_folio
> * and its caller can see stale page cache entries.
> */
> - folio_ref_unfreeze(folio, 1 +
> - ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
> + expected_refs = folio_expected_ref_count(folio) + 1;
> + folio_ref_unfreeze(folio, expected_refs);
>
> unlock_page_lruvec(lruvec);
>
> --
> 2.47.2
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-17 14:07 ` Lorenzo Stoakes
@ 2025-07-17 15:41 ` Zi Yan
2025-07-17 17:44 ` Lorenzo Stoakes
0 siblings, 1 reply; 15+ messages in thread
From: Zi Yan @ 2025-07-17 15:41 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On 17 Jul 2025, at 10:07, Lorenzo Stoakes wrote:
> On Mon, Jul 14, 2025 at 01:18:22PM -0400, Zi Yan wrote:
>> remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
>> splitting unmapped folio operations. Move them out to the caller so that
>> __split_unmapped_folio() only handles unmapped folio splits. This makes
>> __split_unmapped_folio() reusable.
>
> Nit but maybe worth mentioning the various renames etc.
You mean release -> new_folio, origin_folio is replaced by folio?
Sure, I can do that.
>
>>
>> Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> Acked-by: Balbir Singh <balbirs@nvidia.com>
>
> After a lot of staring, 2 difftastic's at once and exactly 0 coverity
> instances, I've convinced myself this looks right.
>
> I think you really should have split this up into smaller patches, as this
> is moving stuff around and changing stuff all at once with a lot of
> complexity and moving parts.
>
> However not going to make you do that, since you got acks and I don't want
> to hold this up.
>
> I have a few nits + queries below that need addressing however, see below.
Since I need to address these nits, I might just split this up.
How about:
1.
>
>> ---
>> mm/huge_memory.c | 291 +++++++++++++++++++++++------------------------
>> 1 file changed, 144 insertions(+), 147 deletions(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 3eb1c34be601..a7ee731f974f 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3396,10 +3396,6 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>> * order - 1 to new_order).
>> * @split_at: in buddy allocator like split, the folio containing @split_at
>> * will be split until its order becomes @new_order.
>> - * @lock_at: the folio containing @lock_at is left locked for caller.
>> - * @list: the after split folios will be added to @list if it is not NULL,
>> - * otherwise to LRU lists.
>> - * @end: the end of the file @folio maps to. -1 if @folio is anonymous memory.
>> * @xas: xa_state pointing to folio->mapping->i_pages and locked by caller
>> * @mapping: @folio->mapping
>> * @uniform_split: if the split is uniform or not (buddy allocator like split)
>> @@ -3425,52 +3421,26 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>> * @page, which is split in next for loop.
>> *
>> * After splitting, the caller's folio reference will be transferred to the
>> - * folio containing @page. The other folios may be freed if they are not mapped.
>> - *
>> - * In terms of locking, after splitting,
>> - * 1. uniform split leaves @page (or the folio contains it) locked;
>> - * 2. buddy allocator like (non-uniform) split leaves @folio locked.
>
> Are these no longer relevant? Shouldn't we retain this, or move it
> elsewhere if appropriate?
With lock_at parameter, people can get this from the __folio_split()
call sites. But a comment is better than none. I will move it to
__folio_split()’s comment area.
>
>> - *
>> + * folio containing @page. The caller needs to unlock and/or free after-split
>> + * folios if necessary.
>> *
>> * For !uniform_split, when -ENOMEM is returned, the original folio might be
>> * split. The caller needs to check the input folio.
>> */
>> static int __split_unmapped_folio(struct folio *folio, int new_order,
>> - struct page *split_at, struct page *lock_at,
>> - struct list_head *list, pgoff_t end,
>> - struct xa_state *xas, struct address_space *mapping,
>> - bool uniform_split)
>> + struct page *split_at, struct xa_state *xas,
>> + struct address_space *mapping, bool uniform_split)
>> {
>> - struct lruvec *lruvec;
>> - struct address_space *swap_cache = NULL;
>> - struct folio *origin_folio = folio;
>> - struct folio *next_folio = folio_next(folio);
>> - struct folio *new_folio;
>> struct folio *next;
>> int order = folio_order(folio);
>> int split_order;
>> int start_order = uniform_split ? new_order : order - 1;
>> - int nr_dropped = 0;
>> int ret = 0;
>> bool stop_split = false;
>>
>> - if (folio_test_swapcache(folio)) {
>> - VM_BUG_ON(mapping);
>
> Good to get rid of this.
>
>> -
>> - /* a swapcache folio can only be uniformly split to order-0 */
>> - if (!uniform_split || new_order != 0)
>> - return -EINVAL;
>> -
>> - swap_cache = swap_address_space(folio->swap);
>> - xa_lock(&swap_cache->i_pages);
>> - }
>> -
>> if (folio_test_anon(folio))
>> mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
>>
>> - /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
>> - lruvec = folio_lruvec_lock(folio);
>> -
>> folio_clear_has_hwpoisoned(folio);
>>
>> /*
>> @@ -3480,9 +3450,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
>> for (split_order = start_order;
>> split_order >= new_order && !stop_split;
>> split_order--) {
>> - int old_order = folio_order(folio);
>> - struct folio *release;
>> struct folio *end_folio = folio_next(folio);
>> + int old_order = folio_order(folio);
>> + struct folio *new_folio;
>>
>> /* order-1 anonymous folio is not supported */
>> if (folio_test_anon(folio) && split_order == 1)
>> @@ -3504,126 +3474,44 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
>> if (xas_error(xas)) {
>> ret = xas_error(xas);
>> stop_split = true;
>> - goto after_split;
>> }
>> }
>> }
>>
>> - folio_split_memcg_refs(folio, old_order, split_order);
>> - split_page_owner(&folio->page, old_order, split_order);
>> - pgalloc_tag_split(folio, old_order, split_order);
>> -
>> - __split_folio_to_order(folio, old_order, split_order);
>> + if (!stop_split) {
>> + folio_split_memcg_refs(folio, old_order, split_order);
>> + split_page_owner(&folio->page, old_order, split_order);
>> + pgalloc_tag_split(folio, old_order, split_order);
>>
>> -after_split:
>> + __split_folio_to_order(folio, old_order, split_order);
>> + }
>> /*
>> - * Iterate through after-split folios and perform related
>> - * operations. But in buddy allocator like split, the folio
>> + * Iterate through after-split folios and update folio stats.
>
> Good to spell out what the 'related operations' are :) Of course you're
> changing this so this loop does some and the other loop does the post-split
> rest.
>
>> + * But in buddy allocator like split, the folio
>> * containing the specified page is skipped until its order
>> * is new_order, since the folio will be worked on in next
>> * iteration.
>> */
>> - for (release = folio; release != end_folio; release = next) {
>> - next = folio_next(release);
>> + for (new_folio = folio; new_folio != end_folio; new_folio = next) {
>> + next = folio_next(new_folio);
>> /*
>> - * for buddy allocator like split, the folio containing
>> - * page will be split next and should not be released,
>> - * until the folio's order is new_order or stop_split
>> - * is set to true by the above xas_split() failure.
>> + * for buddy allocator like split, new_folio containing
>> + * page could be split again, thus do not change stats
>> + * yet. Wait until new_folio's order is new_order or
>> + * stop_split is set to true by the above xas_split()
>> + * failure.
>> */
>> - if (release == page_folio(split_at)) {
>> - folio = release;
>> + if (new_folio == page_folio(split_at)) {
>> + folio = new_folio;
>> if (split_order != new_order && !stop_split)
>> continue;
>> }
>> - if (folio_test_anon(release)) {
>> - mod_mthp_stat(folio_order(release),
>> - MTHP_STAT_NR_ANON, 1);
>> - }
>> -
>> - /*
>> - * origin_folio should be kept frozon until page cache
>> - * entries are updated with all the other after-split
>> - * folios to prevent others seeing stale page cache
>> - * entries.
>> - */
>> - if (release == origin_folio)
>> - continue;
>> -
>> - folio_ref_unfreeze(release, 1 +
>> - ((mapping || swap_cache) ?
>> - folio_nr_pages(release) : 0));
>> -
>> - lru_add_split_folio(origin_folio, release, lruvec,
>> - list);
>> -
>> - /* Some pages can be beyond EOF: drop them from cache */
>> - if (release->index >= end) {
>> - if (shmem_mapping(mapping))
>> - nr_dropped += folio_nr_pages(release);
>> - else if (folio_test_clear_dirty(release))
>> - folio_account_cleaned(release,
>> - inode_to_wb(mapping->host));
>> - __filemap_remove_folio(release, NULL);
>> - folio_put_refs(release, folio_nr_pages(release));
>> - } else if (mapping) {
>> - __xa_store(&mapping->i_pages,
>> - release->index, release, 0);
>> - } else if (swap_cache) {
>> - __xa_store(&swap_cache->i_pages,
>> - swap_cache_index(release->swap),
>> - release, 0);
>> - }
>> + if (folio_test_anon(new_folio))
>> + mod_mthp_stat(folio_order(new_folio),
>> + MTHP_STAT_NR_ANON, 1);
>> }
>> }
>>
>> - /*
>> - * Unfreeze origin_folio only after all page cache entries, which used
>> - * to point to it, have been updated with new folios. Otherwise,
>> - * a parallel folio_try_get() can grab origin_folio and its caller can
>> - * see stale page cache entries.
>> - */
>> - folio_ref_unfreeze(origin_folio, 1 +
>> - ((mapping || swap_cache) ? folio_nr_pages(origin_folio) : 0));
>> -
>> - unlock_page_lruvec(lruvec);
>> -
>> - if (swap_cache)
>> - xa_unlock(&swap_cache->i_pages);
>> - if (mapping)
>> - xa_unlock(&mapping->i_pages);
>> -
>> - /* Caller disabled irqs, so they are still disabled here */
>> - local_irq_enable();
>> -
>> - if (nr_dropped)
>> - shmem_uncharge(mapping->host, nr_dropped);
>> -
>> - remap_page(origin_folio, 1 << order,
>> - folio_test_anon(origin_folio) ?
>> - RMP_USE_SHARED_ZEROPAGE : 0);
>> -
>> - /*
>> - * At this point, folio should contain the specified page.
>> - * For uniform split, it is left for caller to unlock.
>> - * For buddy allocator like split, the first after-split folio is left
>> - * for caller to unlock.
>> - */
>> - for (new_folio = origin_folio; new_folio != next_folio; new_folio = next) {
>> - next = folio_next(new_folio);
>> - if (new_folio == page_folio(lock_at))
>> - continue;
>> -
>> - folio_unlock(new_folio);
>> - /*
>> - * Subpages may be freed if there wasn't any mapping
>> - * like if add_to_swap() is running on a lru page that
>> - * had its mapping zapped. And freeing these pages
>> - * requires taking the lru_lock so we do the put_page
>> - * of the tail pages after the split is complete.
>> - */
>> - free_folio_and_swap_cache(new_folio);
>> - }
>> return ret;
>> }
>>
>> @@ -3706,10 +3594,13 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>> {
>> struct deferred_split *ds_queue = get_deferred_split_queue(folio);
>> XA_STATE(xas, &folio->mapping->i_pages, folio->index);
>> + struct folio *next_folio = folio_next(folio);
>> bool is_anon = folio_test_anon(folio);
>> struct address_space *mapping = NULL;
>> struct anon_vma *anon_vma = NULL;
>> int order = folio_order(folio);
>> + struct folio *new_folio, *next;
>> + int nr_shmem_dropped = 0;
>> int extra_pins, ret;
>> pgoff_t end;
>> bool is_hzp;
>
> There's some VM_BUG_ON_FOLIO()'s in the code:
>
> VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
>
> That should probably be VM_WARN_ON() or VM_WARN_ON_ONCE(), maybe worth
> changing here too?
Sure. I can convert them in a separate patch. Basically:
if (!folio_test_locked(folio)) {
VM_WARN_ON_ONCE_FOLIO(1, folio);
return -EINVAL;
}
if (!folio_test_large(folio)) {
VM_WARN_ON_ONCE_FOLIO(1, folio);
return -EINVAL;
}
>
>> @@ -3833,13 +3724,18 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>> */
>> xas_lock(&xas);
>> xas_reset(&xas);
>> - if (xas_load(&xas) != folio)
>> + if (xas_load(&xas) != folio) {
>> + ret = -EAGAIN;
>
> It is beyond words that the original logic manually set ret == -EAGAIN...
>
> And this is the only place we 'goto fail'.
>
> Yikes this code is a horror show.
>
>
>> goto fail;
>> + }
>> }
>>
>> /* Prevent deferred_split_scan() touching ->_refcount */
>> spin_lock(&ds_queue->split_queue_lock);
>> if (folio_ref_freeze(folio, 1 + extra_pins)) {
>> + struct address_space *swap_cache = NULL;
>> + struct lruvec *lruvec;
>> +
>> if (folio_order(folio) > 1 &&
>> !list_empty(&folio->_deferred_list)) {
>> ds_queue->split_queue_len--;
>> @@ -3873,18 +3769,119 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>> }
>> }
>>
>> - ret = __split_unmapped_folio(folio, new_order,
>> - split_at, lock_at, list, end, &xas, mapping,
>> - uniform_split);
>> + if (folio_test_swapcache(folio)) {
>> + if (mapping) {
>> + VM_WARN_ON_ONCE_FOLIO(mapping, folio);
>> + ret = -EINVAL;
>> + goto fail;
>
> It's a new code path (in prod we'd just carry on, or in debug we would
> haven oops'd), but I think valid.
>
> I wonder if this is almost over-cautious, as this would require a non-anon
> folio to be in the swap-cache (since the is_anon path will set mapping
> NUL).
>
> But at the same time, probably worth keeping in at least for now.
Originally, it is a VM_BUG_ON(mapping). I am converting it to a warning.
I will move it to a separate patch to avoid confusion.
>
>> + }
>> +
>> + /*
>> + * a swapcache folio can only be uniformly split to
>> + * order-0
>> + */
>> + if (!uniform_split || new_order != 0) {
>> + ret = -EINVAL;
>> + goto fail;
>> + }
>> +
>> + swap_cache = swap_address_space(folio->swap);
>> + xa_lock(&swap_cache->i_pages);
>> + }
>> +
>> + /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
>> + lruvec = folio_lruvec_lock(folio);
>> +
>> + ret = __split_unmapped_folio(folio, new_order, split_at, &xas,
>> + mapping, uniform_split);
>> +
>> + /*
>> + * Unfreeze after-split folios and put them back to the right
>> + * list. @folio should be kept frozon until page cache entries
>> + * are updated with all the other after-split folios to prevent
>> + * others seeing stale page cache entries.
>> + */
>> + for (new_folio = folio_next(folio); new_folio != next_folio;
>> + new_folio = next) {
>
> Hm now we have 'next' and 'next_folio', this is quite confusing.
>
> Seems to me new_folio should be end_folio no, like the original? And maybe
> then rename next to next_folio? As it is kinda inconsistent that it isn't
> suffixed with _folio anyway.
Sure. Will do. next_folio was coming from __split_unmapped_folio() code,
I should have renamed it. Thanks for pointing it out.
>
>> + next = folio_next(new_folio);
>> +
>
> We're no longer doing what would here be new_folio == origin_folio
> (previously, release == origin_folio).
>
> Is this correct? Why do we no longer ned to do this?
>
> Is it because __split_unmapped_folio() will somehow take care of this in
> advance/render this meaningless?
>
> This definitely needs to be mentioned in the commit message.
Because “new_folio = folio_next(folio)” in the for loop initialization
part. The @folio is skipped at the very beginning. I will add a comment
to highlight this, since the code change is too subtle.
>
>> + folio_ref_unfreeze(
>> + new_folio,
>> + 1 + ((mapping || swap_cache) ?
>> + folio_nr_pages(new_folio) :
>> + 0));
>
> Again, be nice to separate this out, but I think in a follow-up not here.
OK.
>
>> +
>> + lru_add_split_folio(folio, new_folio, lruvec, list);
>> +
>> + /* Some pages can be beyond EOF: drop them from cache */
>> + if (new_folio->index >= end) {
>> + if (shmem_mapping(mapping))
>> + nr_shmem_dropped += folio_nr_pages(new_folio);
>> + else if (folio_test_clear_dirty(new_folio))
>> + folio_account_cleaned(
>> + new_folio,
>> + inode_to_wb(mapping->host));
>> + __filemap_remove_folio(new_folio, NULL);
>> + folio_put_refs(new_folio,
>> + folio_nr_pages(new_folio));
>> + } else if (mapping) {
>> + __xa_store(&mapping->i_pages, new_folio->index,
>> + new_folio, 0);
>> + } else if (swap_cache) {
>> + __xa_store(&swap_cache->i_pages,
>> + swap_cache_index(new_folio->swap),
>> + new_folio, 0);
>> + }
>> + }
>> + /*
>> + * Unfreeze @folio only after all page cache entries, which
>> + * used to point to it, have been updated with new folios.
>> + * Otherwise, a parallel folio_try_get() can grab origin_folio
>> + * and its caller can see stale page cache entries.
>> + */
>> + folio_ref_unfreeze(folio, 1 +
>> + ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
>
> This line is horrid, probably one for a future series but this sort of
> calculation of what the number of refs should be post-freeze should clearly
> be separated out or at least made abundantly clear in an open-coded
> implementation.
It is addressed in patch 2. And you already noticed it. :)
>
>> +
>> + unlock_page_lruvec(lruvec);
>> +
>> + if (swap_cache)
>> + xa_unlock(&swap_cache->i_pages);
>> } else {
>> spin_unlock(&ds_queue->split_queue_lock);
>> -fail:
>> - if (mapping)
>> - xas_unlock(&xas);
>> - local_irq_enable();
>> - remap_page(folio, folio_nr_pages(folio), 0);
>> ret = -EAGAIN;
>> }
>> +fail:
>> + if (mapping)
>> + xas_unlock(&xas);
>> +
>> + local_irq_enable();
>> +
>> + if (nr_shmem_dropped)
>> + shmem_uncharge(mapping->host, nr_shmem_dropped);
>> +
>> + remap_page(folio, 1 << order,
>> + !ret && folio_test_anon(folio) ? RMP_USE_SHARED_ZEROPAGE :
>> + 0);
>
> I really don't like this !ret but here, this isn't very readable.
>
> Something like:
>
> int flags;
>
> ...
>
> if (!ret && folio_test_anon(folio))
> flags = RMP_USE_SHARED_ZERO_PAGE;
> remap_page(folio, 1 << order, flags);
>
> Would be better.
>
> But really this is all screaming out to be separated into parts of
> course. But that's one for a follow-up series...
Sure. Will add another patch to address this.
>
>> +
>> + /*
>> + * Unlock all after-split folios except the one containing @lock_at
>> + * page. If @folio is not split, it will be kept locked.
>> + */
>> + for (new_folio = folio; new_folio != next_folio; new_folio = next) {
>> + next = folio_next(new_folio);
>> + if (new_folio == page_folio(lock_at))
>> + continue;
>> +
>> + folio_unlock(new_folio);
>> + /*
>> + * Subpages may be freed if there wasn't any mapping
>> + * like if add_to_swap() is running on a lru page that
>> + * had its mapping zapped. And freeing these pages
>> + * requires taking the lru_lock so we do the put_page
>> + * of the tail pages after the split is complete.
>> + */
>> + free_folio_and_swap_cache(new_folio);
>> + }
>>
>> out_unlock:
>> if (anon_vma) {
>> --
>> 2.47.2
>>
>
> Generally I see why you're not using origin_folio any more since you can
> just use folio everywhere, but I wonder if this makes things more
> confusing.
>
> On the other hand, this function is already hugely confusing so maybe not a
> big deal and can be addressed in follow ups...
Since it is causing confusion. I will use origin_folio in the moved code.
I will send V4 to address your comments and add
“mm/huge_memory: refactor after-split (page) cache code.” in.
Best Regards,
Yan, Zi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 0/2] __folio_split() clean up.
2025-07-17 12:40 ` [PATCH v3 0/2] __folio_split() clean up Lorenzo Stoakes
@ 2025-07-17 15:54 ` Zi Yan
2025-07-17 17:39 ` Lorenzo Stoakes
2025-07-17 22:35 ` Andrew Morton
1 sibling, 1 reply; 15+ messages in thread
From: Zi Yan @ 2025-07-17 15:54 UTC (permalink / raw)
To: Andrew Morton, Lorenzo Stoakes
Cc: Balbir Singh, David Hildenbrand, linux-mm, Hugh Dickins,
Kirill Shutemov, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On 17 Jul 2025, at 8:40, Lorenzo Stoakes wrote:
> Hm something has gone weird in mm-new with this.
>
> The patches are in the correct order, but the 2/2 patch, 'mm/huge_memory: use
> folio_expected_ref_count() to calculate ref_count.' contains the cover letter
> and has the suffix:
>
> This patch (of 2):
>
> Instead of open coding the ref_count calculation, use
> folio_expected_ref_count()
>
> But immediately prior to it is 1/2 - mm/huge_memory: move unrelated code
> out of __split_unmapped_folio() but with no cover letter reference.
>
> Andrew - has quilt got confused here? :)
Since I am going to send V3 (also include after-split page cache code patch),
maybe Andrew can drop this series and
“mm/huge_memory: refactor after-split (page) cache code”. Hopefully
we can get everything right in V3.
>
> Thanks, Lorenzo
>
> On Mon, Jul 14, 2025 at 01:18:21PM -0400, Zi Yan wrote:
>> Based on the prior discussion[1], this patch improves
>> __split_unmapped_folio() by making it reusable for splitting unmapped
>> folios. This helps avoid the need for a new boolean unmapped parameter
>> to guard mapping-related code.
>>
>> An additional benefit is that __split_unmapped_folio() could be
>> called on after-split folios by __folio_split(). It can enable new split
>> methods. For example, at deferred split time, unmapped subpages can
>> scatter arbitrarily within a large folio, neither uniform nor non-uniform
>> split can maximize after-split folio orders for mapped subpages.
>> The hope is that by calling __split_unmapped_folio() multiple times,
>> a better split result can be achieved.
>>
>> It passed mm selftests.
>>
>>
>> Changelog
>> ===
>> From V2[3]:
>> 1. Code format fixes
>> 2. Restructured code to remove after_split goto label.
>>
>> From V1[2]:
>> 1. Fixed indentations.
>> 2. Used folio_expected_ref_count() to calculate ref_count instead of
>> open coding.
>>
>>
>> [1] https://lore.kernel.org/linux-mm/94D8C1A4-780C-4BEC-A336-7D3613B54845@nvidia.com/
>> [2] https://lore.kernel.org/linux-mm/20250711030259.3574392-1-ziy@nvidia.com/
>> [2] https://lore.kernel.org/linux-mm/20250711182355.3592618-1-ziy@nvidia.com/
>>
>> Zi Yan (2):
>> mm/huge_memory: move unrelated code out of __split_unmapped_folio()
>> mm/huge_memory: use folio_expected_ref_count() to calculate ref_count.
>>
>> mm/huge_memory.c | 289 +++++++++++++++++++++++------------------------
>> 1 file changed, 142 insertions(+), 147 deletions(-)
>>
>> --
>> 2.47.2
>>
Best Regards,
Yan, Zi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 0/2] __folio_split() clean up.
2025-07-17 15:54 ` Zi Yan
@ 2025-07-17 17:39 ` Lorenzo Stoakes
0 siblings, 0 replies; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 17:39 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Balbir Singh, David Hildenbrand, linux-mm,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Thu, Jul 17, 2025 at 11:54:36AM -0400, Zi Yan wrote:
> On 17 Jul 2025, at 8:40, Lorenzo Stoakes wrote:
>
> > Hm something has gone weird in mm-new with this.
> >
> > The patches are in the correct order, but the 2/2 patch, 'mm/huge_memory: use
> > folio_expected_ref_count() to calculate ref_count.' contains the cover letter
> > and has the suffix:
> >
> > This patch (of 2):
> >
> > Instead of open coding the ref_count calculation, use
> > folio_expected_ref_count()
> >
> > But immediately prior to it is 1/2 - mm/huge_memory: move unrelated code
> > out of __split_unmapped_folio() but with no cover letter reference.
> >
> > Andrew - has quilt got confused here? :)
>
> Since I am going to send V3 (also include after-split page cache code patch),
> maybe Andrew can drop this series and
> “mm/huge_memory: refactor after-split (page) cache code”. Hopefully
> we can get everything right in V3.
Cool yeah simpler :)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-17 15:41 ` Zi Yan
@ 2025-07-17 17:44 ` Lorenzo Stoakes
2025-07-17 18:05 ` Zi Yan
0 siblings, 1 reply; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 17:44 UTC (permalink / raw)
To: Zi Yan
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Thu, Jul 17, 2025 at 11:41:01AM -0400, Zi Yan wrote:
> On 17 Jul 2025, at 10:07, Lorenzo Stoakes wrote:
>
> > On Mon, Jul 14, 2025 at 01:18:22PM -0400, Zi Yan wrote:
> >> remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
> >> splitting unmapped folio operations. Move them out to the caller so that
> >> __split_unmapped_folio() only handles unmapped folio splits. This makes
> >> __split_unmapped_folio() reusable.
> >
> > Nit but maybe worth mentioning the various renames etc.
>
> You mean release -> new_folio, origin_folio is replaced by folio?
> Sure, I can do that.
Yeah that kind of thing, just basically briefly mention the other stuff you
did.
Thanks!
>
> >
> >>
> >> Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
> >>
> >> Signed-off-by: Zi Yan <ziy@nvidia.com>
> >> Acked-by: Balbir Singh <balbirs@nvidia.com>
> >
> > After a lot of staring, 2 difftastic's at once and exactly 0 coverity
> > instances, I've convinced myself this looks right.
> >
> > I think you really should have split this up into smaller patches, as this
> > is moving stuff around and changing stuff all at once with a lot of
> > complexity and moving parts.
> >
> > However not going to make you do that, since you got acks and I don't want
> > to hold this up.
> >
> > I have a few nits + queries below that need addressing however, see below.
>
> Since I need to address these nits, I might just split this up.
> How about:
>
> 1.
Missing some text? :P
> >> @@ -3706,10 +3594,13 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> >> {
> >> struct deferred_split *ds_queue = get_deferred_split_queue(folio);
> >> XA_STATE(xas, &folio->mapping->i_pages, folio->index);
> >> + struct folio *next_folio = folio_next(folio);
> >> bool is_anon = folio_test_anon(folio);
> >> struct address_space *mapping = NULL;
> >> struct anon_vma *anon_vma = NULL;
> >> int order = folio_order(folio);
> >> + struct folio *new_folio, *next;
> >> + int nr_shmem_dropped = 0;
> >> int extra_pins, ret;
> >> pgoff_t end;
> >> bool is_hzp;
> >
> > There's some VM_BUG_ON_FOLIO()'s in the code:
> >
> > VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
> > VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
> >
> > That should probably be VM_WARN_ON() or VM_WARN_ON_ONCE(), maybe worth
> > changing here too?
>
> Sure. I can convert them in a separate patch. Basically:
>
> if (!folio_test_locked(folio)) {
> VM_WARN_ON_ONCE_FOLIO(1, folio);
> return -EINVAL;
> }
>
> if (!folio_test_large(folio)) {
> VM_WARN_ON_ONCE_FOLIO(1, folio);
> return -EINVAL;
> }
Sounds good thanks!
>
> >
> >> @@ -3833,13 +3724,18 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> >> */
> >> xas_lock(&xas);
> >> xas_reset(&xas);
> >> - if (xas_load(&xas) != folio)
> >> + if (xas_load(&xas) != folio) {
> >> + ret = -EAGAIN;
> >
> > It is beyond words that the original logic manually set ret == -EAGAIN...
> >
> > And this is the only place we 'goto fail'.
> >
> > Yikes this code is a horror show.
> >
> >
> >> goto fail;
> >> + }
> >> }
> >>
> >> /* Prevent deferred_split_scan() touching ->_refcount */
> >> spin_lock(&ds_queue->split_queue_lock);
> >> if (folio_ref_freeze(folio, 1 + extra_pins)) {
> >> + struct address_space *swap_cache = NULL;
> >> + struct lruvec *lruvec;
> >> +
> >> if (folio_order(folio) > 1 &&
> >> !list_empty(&folio->_deferred_list)) {
> >> ds_queue->split_queue_len--;
> >> @@ -3873,18 +3769,119 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> >> }
> >> }
> >>
> >> - ret = __split_unmapped_folio(folio, new_order,
> >> - split_at, lock_at, list, end, &xas, mapping,
> >> - uniform_split);
> >> + if (folio_test_swapcache(folio)) {
> >> + if (mapping) {
> >> + VM_WARN_ON_ONCE_FOLIO(mapping, folio);
> >> + ret = -EINVAL;
> >> + goto fail;
> >
> > It's a new code path (in prod we'd just carry on, or in debug we would
> > haven oops'd), but I think valid.
> >
> > I wonder if this is almost over-cautious, as this would require a non-anon
> > folio to be in the swap-cache (since the is_anon path will set mapping
> > NUL).
> >
> > But at the same time, probably worth keeping in at least for now.
>
> Originally, it is a VM_BUG_ON(mapping). I am converting it to a warning.
> I will move it to a separate patch to avoid confusion.
Thanks
>
> >
> >> + }
> >> +
> >> + /*
> >> + * a swapcache folio can only be uniformly split to
> >> + * order-0
> >> + */
> >> + if (!uniform_split || new_order != 0) {
> >> + ret = -EINVAL;
> >> + goto fail;
> >> + }
> >> +
> >> + swap_cache = swap_address_space(folio->swap);
> >> + xa_lock(&swap_cache->i_pages);
> >> + }
> >> +
> >> + /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
> >> + lruvec = folio_lruvec_lock(folio);
> >> +
> >> + ret = __split_unmapped_folio(folio, new_order, split_at, &xas,
> >> + mapping, uniform_split);
> >> +
> >> + /*
> >> + * Unfreeze after-split folios and put them back to the right
> >> + * list. @folio should be kept frozon until page cache entries
> >> + * are updated with all the other after-split folios to prevent
> >> + * others seeing stale page cache entries.
> >> + */
> >> + for (new_folio = folio_next(folio); new_folio != next_folio;
> >> + new_folio = next) {
> >
> > Hm now we have 'next' and 'next_folio', this is quite confusing.
> >
> > Seems to me new_folio should be end_folio no, like the original? And maybe
> > then rename next to next_folio? As it is kinda inconsistent that it isn't
> > suffixed with _folio anyway.
>
> Sure. Will do. next_folio was coming from __split_unmapped_folio() code,
> I should have renamed it. Thanks for pointing it out.
Thanks, yeah this was existing cofusion and not your fault, but good to
make it easier to understand.
>
> >
> >> + next = folio_next(new_folio);
> >> +
> >
> > We're no longer doing what would here be new_folio == origin_folio
> > (previously, release == origin_folio).
> >
> > Is this correct? Why do we no longer ned to do this?
> >
> > Is it because __split_unmapped_folio() will somehow take care of this in
> > advance/render this meaningless?
> >
> > This definitely needs to be mentioned in the commit message.
>
> Because “new_folio = folio_next(folio)” in the for loop initialization
> part. The @folio is skipped at the very beginning. I will add a comment
> to highlight this, since the code change is too subtle.
Ahh yes, that is quite subtle, a comment would be helpful, thanks!
>
> >
> >> + folio_ref_unfreeze(
> >> + new_folio,
> >> + 1 + ((mapping || swap_cache) ?
> >> + folio_nr_pages(new_folio) :
> >> + 0));
> >
> > Again, be nice to separate this out, but I think in a follow-up not here.
>
> OK.
Well, actually no - you fix this in the next patch :P
>
> >
> >> +
> >> + lru_add_split_folio(folio, new_folio, lruvec, list);
> >> +
> >> + /* Some pages can be beyond EOF: drop them from cache */
> >> + if (new_folio->index >= end) {
> >> + if (shmem_mapping(mapping))
> >> + nr_shmem_dropped += folio_nr_pages(new_folio);
> >> + else if (folio_test_clear_dirty(new_folio))
> >> + folio_account_cleaned(
> >> + new_folio,
> >> + inode_to_wb(mapping->host));
> >> + __filemap_remove_folio(new_folio, NULL);
> >> + folio_put_refs(new_folio,
> >> + folio_nr_pages(new_folio));
> >> + } else if (mapping) {
> >> + __xa_store(&mapping->i_pages, new_folio->index,
> >> + new_folio, 0);
> >> + } else if (swap_cache) {
> >> + __xa_store(&swap_cache->i_pages,
> >> + swap_cache_index(new_folio->swap),
> >> + new_folio, 0);
> >> + }
> >> + }
> >> + /*
> >> + * Unfreeze @folio only after all page cache entries, which
> >> + * used to point to it, have been updated with new folios.
> >> + * Otherwise, a parallel folio_try_get() can grab origin_folio
> >> + * and its caller can see stale page cache entries.
> >> + */
> >> + folio_ref_unfreeze(folio, 1 +
> >> + ((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
> >
> > This line is horrid, probably one for a future series but this sort of
> > calculation of what the number of refs should be post-freeze should clearly
> > be separated out or at least made abundantly clear in an open-coded
> > implementation.
>
> It is addressed in patch 2. And you already noticed it. :)
Haha yes, always like it when that happens :)
>
> >
> >> +
> >> + unlock_page_lruvec(lruvec);
> >> +
> >> + if (swap_cache)
> >> + xa_unlock(&swap_cache->i_pages);
> >> } else {
> >> spin_unlock(&ds_queue->split_queue_lock);
> >> -fail:
> >> - if (mapping)
> >> - xas_unlock(&xas);
> >> - local_irq_enable();
> >> - remap_page(folio, folio_nr_pages(folio), 0);
> >> ret = -EAGAIN;
> >> }
> >> +fail:
> >> + if (mapping)
> >> + xas_unlock(&xas);
> >> +
> >> + local_irq_enable();
> >> +
> >> + if (nr_shmem_dropped)
> >> + shmem_uncharge(mapping->host, nr_shmem_dropped);
> >> +
> >> + remap_page(folio, 1 << order,
> >> + !ret && folio_test_anon(folio) ? RMP_USE_SHARED_ZEROPAGE :
> >> + 0);
> >
> > I really don't like this !ret but here, this isn't very readable.
> >
> > Something like:
> >
> > int flags;
> >
> > ...
> >
> > if (!ret && folio_test_anon(folio))
> > flags = RMP_USE_SHARED_ZERO_PAGE;
> > remap_page(folio, 1 << order, flags);
> >
> > Would be better.
> >
> > But really this is all screaming out to be separated into parts of
> > course. But that's one for a follow-up series...
>
> Sure. Will add another patch to address this.
Thanks!
>
> >
> >> +
> >> + /*
> >> + * Unlock all after-split folios except the one containing @lock_at
> >> + * page. If @folio is not split, it will be kept locked.
> >> + */
> >> + for (new_folio = folio; new_folio != next_folio; new_folio = next) {
> >> + next = folio_next(new_folio);
> >> + if (new_folio == page_folio(lock_at))
> >> + continue;
> >> +
> >> + folio_unlock(new_folio);
> >> + /*
> >> + * Subpages may be freed if there wasn't any mapping
> >> + * like if add_to_swap() is running on a lru page that
> >> + * had its mapping zapped. And freeing these pages
> >> + * requires taking the lru_lock so we do the put_page
> >> + * of the tail pages after the split is complete.
> >> + */
> >> + free_folio_and_swap_cache(new_folio);
> >> + }
> >>
> >> out_unlock:
> >> if (anon_vma) {
> >> --
> >> 2.47.2
> >>
> >
> > Generally I see why you're not using origin_folio any more since you can
> > just use folio everywhere, but I wonder if this makes things more
> > confusing.
> >
> > On the other hand, this function is already hugely confusing so maybe not a
> > big deal and can be addressed in follow ups...
>
> Since it is causing confusion. I will use origin_folio in the moved code.
Thanks!
>
> I will send V4 to address your comments and add
> “mm/huge_memory: refactor after-split (page) cache code.” in.
Much appreciated :)
>
> Best Regards,
> Yan, Zi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-17 17:44 ` Lorenzo Stoakes
@ 2025-07-17 18:05 ` Zi Yan
2025-07-17 18:07 ` Lorenzo Stoakes
0 siblings, 1 reply; 15+ messages in thread
From: Zi Yan @ 2025-07-17 18:05 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On 17 Jul 2025, at 13:44, Lorenzo Stoakes wrote:
> On Thu, Jul 17, 2025 at 11:41:01AM -0400, Zi Yan wrote:
>> On 17 Jul 2025, at 10:07, Lorenzo Stoakes wrote:
>>
>>> On Mon, Jul 14, 2025 at 01:18:22PM -0400, Zi Yan wrote:
>>>> remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to
>>>> splitting unmapped folio operations. Move them out to the caller so that
>>>> __split_unmapped_folio() only handles unmapped folio splits. This makes
>>>> __split_unmapped_folio() reusable.
>>>
>>> Nit but maybe worth mentioning the various renames etc.
>>
>> You mean release -> new_folio, origin_folio is replaced by folio?
>> Sure, I can do that.
>
> Yeah that kind of thing, just basically briefly mention the other stuff you
> did.
>
> Thanks!
>
>>
>>>
>>>>
>>>> Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO().
>>>>
>>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>>> Acked-by: Balbir Singh <balbirs@nvidia.com>
>>>
>>> After a lot of staring, 2 difftastic's at once and exactly 0 coverity
>>> instances, I've convinced myself this looks right.
>>>
>>> I think you really should have split this up into smaller patches, as this
>>> is moving stuff around and changing stuff all at once with a lot of
>>> complexity and moving parts.
>>>
>>> However not going to make you do that, since you got acks and I don't want
>>> to hold this up.
>>>
>>> I have a few nits + queries below that need addressing however, see below.
>>
>> Since I need to address these nits, I might just split this up.
>> How about:
>>
>> 1.
>
> Missing some text? :P
Yeah, I meant to fill this up after going through your comments below.
The plan is:
1. Just move code from __split_unmapped_folio() to __folio_split().
2. one patch to remove after_split label
3. one patch to move fail label and related code
4. one patch to refactor remap_page() flag
5. one patch to convert VM_BUG* to VM_WARM*, three instances.
6. use folio_expected_ref_count() patch
7. mm/huge_memory: refactor after-split (page) cache code.
Maybe 2, 3, 4 can be squashed into a single refactor patch?
Best Regards,
Yan, Zi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio()
2025-07-17 18:05 ` Zi Yan
@ 2025-07-17 18:07 ` Lorenzo Stoakes
0 siblings, 0 replies; 15+ messages in thread
From: Lorenzo Stoakes @ 2025-07-17 18:07 UTC (permalink / raw)
To: Zi Yan
Cc: Balbir Singh, David Hildenbrand, linux-mm, Andrew Morton,
Hugh Dickins, Kirill Shutemov, Baolin Wang, Liam R. Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Thu, Jul 17, 2025 at 02:05:06PM -0400, Zi Yan wrote:
> Yeah, I meant to fill this up after going through your comments below.
> The plan is:
>
> 1. Just move code from __split_unmapped_folio() to __folio_split().
> 2. one patch to remove after_split label
> 3. one patch to move fail label and related code
> 4. one patch to refactor remap_page() flag
> 5. one patch to convert VM_BUG* to VM_WARM*, three instances.
> 6. use folio_expected_ref_count() patch
> 7. mm/huge_memory: refactor after-split (page) cache code.
>
> Maybe 2, 3, 4 can be squashed into a single refactor patch?
>
> Best Regards,
> Yan, Zi
Will leave to your discretion as to how best to structure :)
Cheers, Lorenzo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 0/2] __folio_split() clean up.
2025-07-17 12:40 ` [PATCH v3 0/2] __folio_split() clean up Lorenzo Stoakes
2025-07-17 15:54 ` Zi Yan
@ 2025-07-17 22:35 ` Andrew Morton
1 sibling, 0 replies; 15+ messages in thread
From: Andrew Morton @ 2025-07-17 22:35 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Balbir Singh, Zi Yan, David Hildenbrand, linux-mm, Hugh Dickins,
Kirill Shutemov, Baolin Wang, Liam R. Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, linux-kernel
On Thu, 17 Jul 2025 13:40:55 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> The patches are in the correct order, but the 2/2 patch, 'mm/huge_memory: use
> folio_expected_ref_count() to calculate ref_count.' contains the cover letter
> and has the suffix:
>
> This patch (of 2):
>
> Instead of open coding the ref_count calculation, use
> folio_expected_ref_count()
>
> But immediately prior to it is 1/2 - mm/huge_memory: move unrelated code
> out of __split_unmapped_folio() but with no cover letter reference.
Doh, I placed the [0/2] inside [2/2] instead of [1/2].
Fixed, I'll hang onto the v3 series - it already has a TBU (to be
updated) akpm-note-to-self.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2025-07-17 22:35 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-14 17:18 [PATCH v3 0/2] __folio_split() clean up Zi Yan
2025-07-14 17:18 ` [PATCH v3 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() Zi Yan
2025-07-14 18:54 ` David Hildenbrand
2025-07-17 14:07 ` Lorenzo Stoakes
2025-07-17 15:41 ` Zi Yan
2025-07-17 17:44 ` Lorenzo Stoakes
2025-07-17 18:05 ` Zi Yan
2025-07-17 18:07 ` Lorenzo Stoakes
2025-07-14 17:18 ` [PATCH v3 2/2] mm/huge_memory: use folio_expected_ref_count() to calculate ref_count Zi Yan
2025-07-17 8:03 ` Baolin Wang
2025-07-17 14:31 ` Lorenzo Stoakes
2025-07-17 12:40 ` [PATCH v3 0/2] __folio_split() clean up Lorenzo Stoakes
2025-07-17 15:54 ` Zi Yan
2025-07-17 17:39 ` Lorenzo Stoakes
2025-07-17 22:35 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).