mm/migrate: Putback split folios when numa hint migration fails
Subsystems (2)
PATCH 1/1 mm/migrate: Putback split folios when numa hint migration fails
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Here the issue is NUMA path (migrate_misplaced_folio()) may start to encounter such folio split now even with MR_NUMA_MISPLACED hint applied. Then when migrate_pages() didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.
Fix it by putting back all the folios on the list.
[1] https://lore.kernel.org/all/[email protected]/
---
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
--- mm/migrate.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
mm/migrate.c +2 -8
@@ -2615,14 +2615,8 @@ int migrate_misplaced_folio(struct folio *folio, struct vm_area_struct *vma, nr_remaining =migrate_pages (&migratepages, alloc_misplaced_dst_folio,NULL , node,MIGRATE_ASYNC ,MR_NUMA_MISPLACED , &nr_succeeded); -if (nr_remaining) { -if (!list_empty (&migratepages)) { -list_del (&folio->lru); -node_stat_mod_folio (folio,NR_ISOLATED_ANON + -folio_is_file_lru (folio), -nr_pages); -folio_putback_lru (folio); - } - } +if (nr_remaining && !list_empty (&migratepages)) +putback_movable_pages (&migratepages);if (nr_succeeded) {count_vm_numa_events (NUMA_PAGE_MIGRATE , nr_succeeded);if (!node_is_toptier (folio_nid (folio)) &&node_is_toptier (node))
Signature · 1 line
2.45.0
Zi Yan
reviewerQuoted 24 lines · Peter Xu
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Here the issue is NUMA path (
migrate_misplaced_folio()) may start to encounter such folio split now even withMR_NUMA_MISPLACEDhint applied. Then whenmigrate_pages()didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.Fix it by putting back all the folios on the list.
[1] https://lore.kernel.org/all/[email protected]/
Cc Zi Yan <[email protected]>Cc Yang Shi <[email protected]>Cc Hugh Dickins <[email protected]>Cc Baolin Wang <[email protected]>Cc Huang Ying <[email protected]>Cc David Hildenbrand <[email protected]>Fixes 7262f208ca68 ("mm/migrate: split source folio if it is on deferred split list")Signed-off-by Peter Xu <[email protected]>
Quoted 6 lines
---
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
--- mm/migrate.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
LGTM. Thanks. Reviewed-by: Zi Yan <[email protected]>
Signature · 2 lines
Best Regards, Yan, Zi
Andrew Morton
maintainerQuoted 6 lines · On Mon, 8 Jul 2024 17:55:37 -0400 Peter Xu <[email protected]> wrote:
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Quoted 7 lines
Here the issue is NUMA path (
migrate_misplaced_folio()) may start to encounter such folio split now even withMR_NUMA_MISPLACEDhint applied. Then whenmigrate_pages()didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.Fix it by putting back all the folios on the list.
mm/migrate.c: In function 'migrate_misplaced_folio':mm/migrate.c:2624:13: error: unused variable 'nr_pages' [-Werror=unused-variable]
2624 | int nr_pages = folio_nr_pages(folio);
| ^~~~~~~~Worrisome. Which kernel version was this tested against?
Quoted 1 line
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
Also worrisome. Are we to take an only-smoke-tested patch which doesn't apply to mainline and which doesn't compile on mm-unstable into mainline based on "only smoke tested"?
Quoted 14 lines · Andrew Morton
Quoted 12 lines · On Mon, 8 Jul 2024 17:55:37 -0400 Peter Xu <[email protected]> wrote:
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Here the issue is NUMA path (
migrate_misplaced_folio()) may start to encounter such folio split now even withMR_NUMA_MISPLACEDhint applied. Then whenmigrate_pages()didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.
Quoted 8 lines
Quoted 1 line
Fix it by putting back all the folios on the list.
mm/migrate.c: In function 'migrate_misplaced_folio':mm/migrate.c:2624:13: error: unused variable 'nr_pages' [-Werror=unused-variable]2624 | int nr_pages = folio_nr_pages(folio); | ^~~~~~~~Worrisome. Which kernel version was this tested against?
mm-unstable (and on top of a few of my other totally irrelevant patches), and I thought it also applied to mm-stable.
Totally missed this warning when still with WERROR=off locally when building against this patch, my apologies.
Quoted 6 lines
Quoted 2 lines
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
Also worrisome. Are we to take an only-smoke-tested patch which doesn't apply to mainline and which doesn't compile on mm-unstable into mainline based on "only smoke tested"?
Hmm so it doesn't apply to mainline.. For the smoke test part, I was not confident to reproduce it, and I just stumbled over it when looking at the real BUG_ON we hit. I thought it might be a good idea to send a patch before everyone forgets about it.
I think it is easily overlooked probably because the issue wasn't obvious. IIUC the sympton of hitting it should be that we leak a few of those tail pages even if they're freed in the future from the mappings. I am not sure how much an issue with keep being !lru for them besides the leaked refcounts, perhaps only vmscan won't see them. After all, all these is based on the chance of hitting this case and it should be rare. I don't think I know well enough to say.
Considering that nobody yelled after rc5 until now, and this is only something I observed when looking at the more severe issue Hugh fixed.. maybe we should target this for next release, then stablize it and wait for a backport to 6.10?
Thanks,
Signature · 1 line
Peter Xu
Andrew Morton
maintainerQuoted 4 lines · On Tue, 9 Jul 2024 10:47:19 -0400 Peter Xu <[email protected]> wrote:
Considering that nobody yelled after rc5 until now, and this is only something I observed when looking at the more severe issue Hugh fixed.. maybe we should target this for next release, then stablize it and wait for a backport to 6.10?
Sure, let's do that.
Quoted 24 lines · Peter Xu
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Here the issue is NUMA path (
migrate_misplaced_folio()) may start to encounter such folio split now even withMR_NUMA_MISPLACEDhint applied. Then whenmigrate_pages()didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.Fix it by putting back all the folios on the list.
[1] https://lore.kernel.org/all/[email protected]/
Cc Zi Yan <[email protected]>Cc Yang Shi <[email protected]>Cc Hugh Dickins <[email protected]>Cc Baolin Wang <[email protected]>Cc Huang Ying <[email protected]>Cc David Hildenbrand <[email protected]>Fixes 7262f208ca68 ("mm/migrate: split source folio if it is on deferred split list")Signed-off-by Peter Xu <[email protected]>
Quoted 1 line
---
Good catch. With fixing the building issue pointed by Andrew, please feel free to add:
Quoted 13 lines
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
--- mm/migrate.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)mm/migrate.c +0
-0@@ -2615,14 +2615,8 @@ int migrate_misplaced_folio(struct folio *folio, struct vm_area_struct *vma, nr_remaining = migrate_pages(&migratepages, alloc_misplaced_dst_folio, NULL, node, MIGRATE_ASYNC,
mm/migrate.c int migrate_misplaced_folio(struct folio *folio, struct vm_area_struct *vma, · line 2618
Quoted 10 lines
mm/migrate.c +1
-8MR_NUMA_MISPLACED, &nr_succeeded); -if (nr_remaining) { -if (!list_empty (&migratepages)) { -list_del (&folio->lru); -node_stat_mod_folio (folio,NR_ISOLATED_ANON + -folio_is_file_lru (folio), -nr_pages); -folio_putback_lru (folio); - } - } +if (nr_remaining && !list_empty (&migratepages))
Nit: you can drop the '!list_empty(&migratepages)' validation, since putback_movable_pages() can handle this unusual case.
Quoted 4 lines
mm/migrate.c +1
-0+putback_movable_pages (&migratepages);if (nr_succeeded) {count_vm_numa_events (NUMA_PAGE_MIGRATE , nr_succeeded);if (!node_is_toptier (folio_nid (folio)) &&node_is_toptier (node))
Quoted 51 lines · Baolin Wang
Quoted 24 lines · Peter Xu
This issue is not from any report yet, but by code observation only.
This is yet another fix besides Hugh's patch [1] but on relevant code path, where eager split of folio can happen if the folio is already on deferred list during a folio migration.
Here the issue is NUMA path (
migrate_misplaced_folio()) may start to encounter such folio split now even withMR_NUMA_MISPLACEDhint applied. Then whenmigrate_pages()didn't migrate all the folios, it's possible the split small folios be put onto the list instead of the original folio. Then putting back only the head page won't be enough.Fix it by putting back all the folios on the list.
[1] https://lore.kernel.org/all/[email protected]/
Cc Zi Yan <[email protected]>Cc Yang Shi <[email protected]>Cc Hugh Dickins <[email protected]>Cc Baolin Wang <[email protected]>Cc Huang Ying <[email protected]>Cc David Hildenbrand <[email protected]>Fixes 7262f208ca68 ("mm/migrate: split source folio if it is on deferred split list")Signed-off-by Peter Xu <[email protected]>Quoted 1 line
---
Good catch. With fixing the building issue pointed by Andrew, please feel free to add:
Reviewed-by Baolin Wang <[email protected]>Quoted 18 lines
Don't need to copy stable if this can still hit 6.10.. Only smoke tested.
--- mm/migrate.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)mm/migrate.c +0
-4@@ -2615,14 +2615,8 @@ int migrate_misplaced_folio(struct folio *folio, struct vm_area_struct *vma, nr_remaining =migrate_pages (&migratepages, alloc_misplaced_dst_folio,NULL , node,MIGRATE_ASYNC ,MR_NUMA_MISPLACED , &nr_succeeded); -if (nr_remaining) { -if (!list_empty (&migratepages)) { -list_del (&folio->lru); - node_stat_mod_folio(folio, NR_ISOLATED_ANON +
Quoted 8 lines
mm/migrate.c int migrate_misplaced_folio(struct folio *folio, struct vm_area_struct *vma, · line 2618
Quoted 5 lines
mm/migrate.c +1
-4- folio_is_file_lru(folio), -nr_pages); -folio_putback_lru (folio); - } - } +if (nr_remaining && !list_empty (&migratepages))Nit: you can drop the '!list_empty(&migratepages)' validation, since
putback_movable_pages()can handle this unusual case.
Sure, considering that it should normally be !empty when the first check passed.
Though to make this simple for now, I assume we can keep what has been queued in Andrew's tree. It isn't so bad either to double check the list to avoid a function call if possible, I think.
Thanks for the comment,
Signature · 1 line
Peter Xu