RFC couple of TLB flush optimisations
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 patches 15 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | Revert "mm: always flush VMA ranges affected by zap_page_range"mm/ | +1 | 2 replies | |
| 2/3 | mm: mmu_gather track of invalidated TLB ranges explicitly for more precise flushinginclude/ mm/ | +28 | 1 reply | |
| 3/3 | powerpc/64s/radix: optimise TLB flush with precise TLB ranges in mmu_gatherarch/ | +5 | 12 replies |
Reviews trailers per patch
1 of 3 patches has a Reviewed-by or Acked-by.
| Patch | Nadav Amit |
|---|---|
| 1/3 | R-b |
| 2/3 | |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC PATCH 0/3] couple of TLB flush optimisations
I'm just looking around TLB flushing and noticed a few issues with the core code. The first one seems pretty straightforward, unless I missed something, but the TLB flush pattern after the revert seems okay.
The second one might be a bit more interesting for other architectures and the big comment in include/asm-generic/tlb.h and linked mail from Linus gives some good context.
I suspect mmu notifiers should use this precise TLB range too, because I don't see how they could care about the page table structure under the mapping. Although I only use it in powerpc so far.
Comments?
Thanks,
Nick
Nicholas Piggin (3):
Revert "mm: always flush VMA ranges affected by zap_page_range"
mm: mmu_gather track of invalidated TLB ranges explicitly for more
precise flushing
powerpc/64s/radix: optimise TLB flush with precise TLB ranges in
mmu_gather
arch/powerpc/mm/tlb-radix.c | 7 +++++-- include/asm-generic/tlb.h | 27 +++++++++++++++++++++++++-- mm/memory.c | 18 ++++-------------- 3 files changed, 34 insertions(+), 18 deletions(-)
Signature · 1 line
2.17.0