diff options
author | Hugh Dickins <hughd@google.com> | 2022-02-14 18:38:47 -0800 |
---|---|---|
committer | Matthew Wilcox (Oracle) <willy@infradead.org> | 2022-02-17 11:59:40 -0500 |
commit | b74355078b6554271371532a5daa3b1a3db620f9 (patch) | |
tree | 2db40bdaeeb1d7842560e2d06b51236d7beb5f3a /mm/khugepaged.c | |
parent | 2fbb0c10d1e8222604132b3a3f81bfd8345a44b6 (diff) | |
download | lwn-b74355078b6554271371532a5daa3b1a3db620f9.tar.gz lwn-b74355078b6554271371532a5daa3b1a3db620f9.zip |
mm/munlock: page migration needs mlock pagevec drained
Page migration of a VM_LOCKED page tends to fail, because when the old
page is unmapped, it is put on the mlock pagevec with raised refcount,
which then fails the freeze.
At first I thought this would be fixed by a local mlock_page_drain() at
the upper rmap_walk() level - which would have nicely batched all the
munlocks of that page; but tests show that the task can too easily move
to another cpu, leaving pagevec residue behind which fails the migration.
So try_to_migrate_one() drain the local pagevec after page_remove_rmap()
from a VM_LOCKED vma; and do the same in try_to_unmap_one(), whose
TTU_IGNORE_MLOCK users would want the same treatment; and do the same
in remove_migration_pte() - not important when successfully inserting
a new page, but necessary when hoping to retry after failure.
Any new pagevec runs the risk of adding a new way of stranding, and we
might discover other corners where mlock_page_drain() or lru_add_drain()
would now help.
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Diffstat (limited to 'mm/khugepaged.c')
0 files changed, 0 insertions, 0 deletions