[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191217123544.GI2827@hirez.programming.kicks-ass.net>
Date: Tue, 17 Dec 2019 13:35:44 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc: akpm@...ux-foundation.org, npiggin@...il.com, mpe@...erman.id.au,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch
allocation failure and flush
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@...radead.org>
> >
> > 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).
Powered by blists - more mailing lists