aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/radix-tree/maple.c
diff options
context:
space:
mode:
authorSeongJae Park <[email protected]>2025-04-10 00:00:21 +0000
committerAndrew Morton <[email protected]>2025-05-12 00:48:27 +0000
commitde8efdf8cd273619121cbc2f0f70dddc74bc586e (patch)
tree2b998aa57d52bc9b90fd00f34d3e71c6932ddc78 /tools/testing/radix-tree/maple.c
parentmm/madvise: batch tlb flushes for MADV_FREE (diff)
downloadkernel-de8efdf8cd273619121cbc2f0f70dddc74bc586e.tar.gz
kernel-de8efdf8cd273619121cbc2f0f70dddc74bc586e.zip
mm/memory: split non-tlb flushing part from zap_page_range_single()
Some of zap_page_range_single() callers such as [process_]madvise() with MADV_DONTNEED[_LOCKED] cannot batch tlb flushes because zap_page_range_single() flushes tlb for each invocation. Split out the body of zap_page_range_single() except mmu_gather object initialization and gathered tlb entries flushing for such batched tlb flushing usage. To avoid hugetlb pages allocation failures from concurrent page faults, the tlb flush should be done before hugetlb faults unlocking, though. Do the flush and the unlock inside the split out function in the order for hugetlb vma case. Refer to commit 2820b0f09be9 ("hugetlbfs: close race between MADV_DONTNEED and page fault") for more details about the concurrent faults' page allocation failure problem. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Diffstat (limited to 'tools/testing/radix-tree/maple.c')
0 files changed, 0 insertions, 0 deletions