summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2015-01-12 19:10:55 +0000
committerLinus Torvalds <torvalds@linux-foundation.org>2015-01-13 15:20:40 +1300
commit721c21c17ab958abf19a8fc611c3bd4743680e38 (patch)
tree592da7d79c7d01a4a4a1ad0353430dee1f147115 /Documentation
parenteaa27f34e91a14cdceed26ed6c6793ec1d186115 (diff)
mm: mmu_gather: use tlb->end != 0 only for TLB invalidation
When batching up address ranges for TLB invalidation, we check tlb->end != 0 to indicate that some pages have actually been unmapped. As of commit f045bbb9fa1b ("mmu_gather: fix over-eager tlb_flush_mmu_free() calling"), we use the same check for freeing these pages in order to avoid a performance regression where we call free_pages_and_swap_cache even when no pages are actually queued up. Unfortunately, the range could have been reset (tlb->end = 0) by tlb_end_vma, which has been shown to cause memory leaks on arm64. Furthermore, investigation into these leaks revealed that the fullmm case on task exit no longer invalidates the TLB, by virtue of tlb->end == 0 (in 3.18, need_flush would have been set). This patch resolves the problem by reverting commit f045bbb9fa1b, using instead tlb->local.nr as the predicate for page freeing in tlb_flush_mmu_free and ensuring that tlb->end is initialised to a non-zero value in the fullmm case. Tested-by: Mark Langsdorf <mlangsdo@redhat.com> Tested-by: Dave Hansen <dave@sr71.net> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions