[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230711075434.10936-1-alexghiti@rivosinc.com>
Date: Tue, 11 Jul 2023 09:54:30 +0200
From: Alexandre Ghiti <alexghiti@...osinc.com>
To: Will Deacon <will@...nel.org>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Mayuresh Chitale <mchitale@...tanamicro.com>,
Vincent Chen <vincent.chen@...ive.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, linux-arch@...r.kernel.org,
linux-mm@...ck.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Cc: Alexandre Ghiti <alexghiti@...osinc.com>
Subject: [PATCH 0/4] riscv: tlb flush improvements
This series optimizes the tlb flushes on riscv which used to simply
flush the whole tlb whatever the size of the range to flush or the size
of the stride.
Patch 3 introduces a threshold that is microarchitecture specific and
will very likely be modified by vendors, not sure though which mechanism
we'll use to do that (dt? alternatives? vendor initialization code?).
Next steps would be to implement:
- svinval extension as Mayuresh did here [1]
- BATCHED_UNMAP_TLB_FLUSH (I'll wait for arm64 patchset to land)
- MMU_GATHER_RCU_TABLE_FREE
- MMU_GATHER_MERGE_VMAS
Any other idea welcome.
[1] https://lore.kernel.org/linux-riscv/20230623123849.1425805-1-mchitale@ventanamicro.com/
Alexandre Ghiti (4):
riscv: Improve flush_tlb()
riscv: Improve flush_tlb_range() for hugetlb pages
riscv: Make __flush_tlb_range() loop over pte instead of flushing the
whole tlb
riscv: Improve flush_tlb_kernel_range()
arch/riscv/include/asm/tlb.h | 6 +-
arch/riscv/include/asm/tlbflush.h | 12 ++--
arch/riscv/mm/tlbflush.c | 93 +++++++++++++++++++++++++++----
3 files changed, 94 insertions(+), 17 deletions(-)
--
2.39.2
Powered by blists - more mailing lists