Luming Yu <luming...@shingroup.cn> writes: > On Sun, Sep 22, 2024 at 04:39:53PM +0530, Ritesh Harjani wrote: >> Luming Yu <luming...@shingroup.cn> writes: >> >> > From: Yu Luming <luming...@gmail.com> >> > >> > ppc always do its own tracking for batch tlb. By trivially enabling >> > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use >> > common code in rmap and reduce overhead and do optimization it could not >> > have without a tlb flushing context at low architecture level. >> >> I looked at this patch and other than the compile failure, this patch >> still won't optimize anything. The idea of this config is that we want >> to batch all the tlb flush operation at the end. By returning false from >> should_defer_flush() (in this patch), we are saying we cannot defer >> the flush and hence we do tlb flush in the same context of unmap. > not exactly, as false return implies, we currently do nothing but relying on > book3S_64's tlb batch implementation which contains a bit of defer > optimization > that we need to use a real benchmark to do some performance characterization. > > And I need to get my test bed ready for patch testing first. So I have to > defer the real optimization in this area. >> >> Anyway, I took a quick look at ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH >> and I have a quick PoC for the same. I will soon post it. > thanks for picking up the barton for the future collaboration on the > potential common performance benefits among us for powerpc arch.
Sure Thanks, Luming. I have posted this work here [1]. [1]: https://lore.kernel.org/linuxppc-dev/cover.1727001426.git.ritesh.l...@gmail.com/ -ritesh
