Luming Yu [off-list ref] writes:

On Sun, Sep 22, 2024 at 04:39:53PM +0530, Ritesh Harjani wrote:

quoted

Luming Yu [off-list ref] writes:

quoted

From: Yu Luming <redacted>

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.

quoted

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.list@gmail.com/ (local)
-ritesh