Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

[Aneesh Kumar K.V]

Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:

> On Tue, Dec 17, 2019 at 04:18:40PM +0530, Aneesh Kumar K.V wrote:
>> On 12/17/19 2:39 PM, Peter Zijlstra wrote:
>> > On Tue, Dec 17, 2019 at 12:47:12PM +0530, Aneesh Kumar K.V wrote:
>> > > Architectures for which we have hardware walkers of Linux page table should
>> > > flush TLB on mmu gather batch allocation failures and batch flush. Some
>> > > architectures like POWER supports multiple translation modes (hash and radix)
>> > > and in the case of POWER only radix translation mode needs the above TLBI.
>> > > This is because for hash translation mode kernel wants to avoid this extra
>> > > flush since there are no hardware walkers of linux page table. With radix
>> > > translation, the hardware also walks linux page table and with that, kernel
>> > > needs to make sure to TLB invalidate page walk cache before page table pages are
>> > > freed.
>> > 
>> > > Based on changes from Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>> > 
>> > AFAICT it is all my patch ;-)
>> 
>> Yes. I moved the changes you had to upstream. I can update the From: in the
>> next version if you are ok with that?
>
> Well, since PPC isn't broken per finding the invalidate in
> __p*_free_tlb(), lets do these things on top of the patches I proposed
> here. Also, you mnight want to run benchmarks to see if the movement of
> that TLBI actually helps (I'm thinking the cost of the PTESYNC might add
> up).

Upstream ppc64 is broken after the commit: a46cc7a90fd8
("powerpc/mm/radix: Improve TLB/PWC flushes").

Also the patches are not adding any extra TLBI on either radix or hash.

Considering we need to backport this to stable and other distributions,
how about we do this early patches in your series before the Kconfig rename?
This should enable stable to pick them up with less dependencies. 

-aneesh