Re: Excessive TLB flush ranges

From: Thomas Gleixner <tglx@linutronix.de>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Christoph Hellwig <hch@lst.de>,
	Uladzislau Rezki <urezki@gmail.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Baoquan He <bhe@redhat.com>, John Ogness <jogness@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	x86@kernel.org, Nadav Amit <nadav.amit@gmail.com>
Subject: Re: Excessive TLB flush ranges
Date: Fri, 19 May 2023 15:49:35 +0200	[thread overview]
Message-ID: <87wn144ej4.ffs@tglx> (raw)
In-Reply-To: <874joc8x7d.ffs@tglx>

On Tue, May 16 2023 at 11:03, Thomas Gleixner wrote:
> On Tue, May 16 2023 at 09:27, Russell King wrote:
>> implementation, there is flush_tlb_kernel_page() though, which I
>> think is what you're referring to above. On ARM32, that will issue
>> one IPI each time it's called, and possibly another IPI for the
>> Cortex-A15 erratum.
>>
>> Given that, flush_tlb_kernel_range() is still going to be more
>> efficient on ARM32 when tlb_ops_need_broadcast() is true than doing
>> it page by page.
>
> Something like the untested below?

The list based individual flush wins over a tlb_flush_all() in that
particular scenario. It's almost in the noise while the TLB flush all
has an impact of ~1% on the other CPUs computation runtime.

That's just a quick check w/o deeper analysis, but that clearly shows
that there is potential.

Whether the list or as Nadav suggested some other storage turns out to
be also benefitial for IPI based flushing is still subject to
investigation.

Thanks,

        tglx

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel