Re: [PATCH 0/4] riscv: tlb flush improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Conor,


On 12/07/2023 09:08, Conor Dooley wrote:
Hey Alex,

On Tue, Jul 11, 2023 at 09:54:30AM +0200, Alexandre Ghiti wrote:
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?).


@Conor any idea how to achieve this?



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@xxxxxxxxxxxxxxxx/

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
The whole series does not build on nommu & this one adds a build warning
for regular builds:
+      1 ../arch/riscv/mm/tlbflush.c:32:15: warning: symbol 'tlb_flush_all_threshold' was not declared. Should it be static?

Cheers,
Conor.


I'll fix the nommu build, sorry about that. Weird I missed this warning, that's an LLVM build right? That variable will need to overwritten by the vendors, so that should not be static (but it will depend on what solution we implement).


Thanks,


Alex






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux