diff options
author | Will Deacon <will.deacon@arm.com> | 2015-01-12 19:10:55 +0000 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2015-01-13 15:20:40 +1300 |
commit | 721c21c17ab958abf19a8fc611c3bd4743680e38 (patch) | |
tree | 592da7d79c7d01a4a4a1ad0353430dee1f147115 /Documentation | |
parent | eaa27f34e91a14cdceed26ed6c6793ec1d186115 (diff) | |
download | linux-721c21c17ab958abf19a8fc611c3bd4743680e38.tar.gz linux-721c21c17ab958abf19a8fc611c3bd4743680e38.tar.bz2 linux-721c21c17ab958abf19a8fc611c3bd4743680e38.zip |
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