On Wed, 3 Jul 2024, Andrew Morton wrote:...
On Tue, 2 Jul 2024 00:40:55 -0700 (PDT) Hugh Dickins <hughd@xxxxxxxxxx> wrote:
And perhaps a conflict with another one of Kefeng's, which deletes a hunk
in mm/migrate.c just above where I add a hunk: and that's indeed how it
should end up, hunk deleted by Kefeng, hunk added by me.
--- mm/memcontrol.c~mm-refactor-folio_undo_large_rmappable
+++ mm/memcontrol.c
@@ -7832,8 +7832,7 @@ void mem_cgroup_migrate(struct folio *ol
* In addition, the old folio is about to be freed after migration, so
* removing from the split queue a bit earlier seems reasonable.
*/
- if (folio_test_large(old) && folio_test_large_rmappable(old))
- folio_undo_large_rmappable(old);
+ folio_undo_large_rmappable(old);
old->memcg_data = 0;
}
I'm resolving this by simply dropping the above hunk. So Kefeng's
patch is now as below. Please check.
Checked, and that is correct, thank you Andrew. Correct, but not quite
complete: because I'm sure that if Kefeng had written his patch after
mine, he would have made the equivalent change in mm/migrate.c:
--- a/mm/migrate.cMaybe we could convert to __folio_undo_large_rmappable() for !maping part, which will avoid unnecessary freeze/unfreeze for empty deferred
+++ b/mm/migrate.c
@@ -443,8 +443,7 @@ int folio_migrate_mapping(struct address_space *mapping,
}
/* Take off deferred split queue while frozen and memcg set */
- if (folio_test_large(folio) && folio_test_large_rmappable(folio))
- folio_undo_large_rmappable(folio);
+ folio_undo_large_rmappable(folio);
/*
* Now we know that no one else is looking at the folio:
But there's no harm done if you push out a tree without that additional
mod: we can add it as a fixup afterwards, it's no more than a cleanup.
(I'm on the lookout for an mm.git update, hope to give it a try when it
appears.)
Thanks,
Hugh