From: Peter Zijlstra <peterz@infradead.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: akpm@linux-foundation.org, npiggin@gmail.com, mpe@ellerman.id.au,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush
Date: Tue, 17 Dec 2019 13:35:44 +0100 [thread overview]
Message-ID: <20191217123544.GI2827@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <3d250b04-a78d-20a7-d41e-50e48e08d1cb@linux.ibm.com>
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@infradead.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).
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, npiggin@gmail.com,
linux-mm@kvack.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush
Date: Tue, 17 Dec 2019 13:35:44 +0100 [thread overview]
Message-ID: <20191217123544.GI2827@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <3d250b04-a78d-20a7-d41e-50e48e08d1cb@linux.ibm.com>
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@infradead.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).
next prev parent reply other threads:[~2019-12-17 12:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 7:17 [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush Aneesh Kumar K.V
2019-12-17 7:17 ` Aneesh Kumar K.V
2019-12-17 7:17 ` [RFC PATCH 2/2] mm/mmu_gather: Avoid multiple page walk cache flush Aneesh Kumar K.V
2019-12-17 7:17 ` Aneesh Kumar K.V
2019-12-17 8:58 ` Peter Zijlstra
2019-12-17 8:58 ` Peter Zijlstra
2019-12-17 10:15 ` Aneesh Kumar K.V
2019-12-17 10:15 ` Aneesh Kumar K.V
2019-12-17 12:34 ` Peter Zijlstra
2019-12-17 12:34 ` Peter Zijlstra
2019-12-17 20:12 ` [PATCH] asm-generic/tlb: Avoid potential double flush Peter Zijlstra
2019-12-17 20:12 ` Peter Zijlstra
2019-12-17 9:09 ` [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush Peter Zijlstra
2019-12-17 9:09 ` Peter Zijlstra
2019-12-17 10:48 ` Aneesh Kumar K.V
2019-12-17 10:48 ` Aneesh Kumar K.V
2019-12-17 12:35 ` Peter Zijlstra [this message]
2019-12-17 12:35 ` Peter Zijlstra
2019-12-18 5:22 ` Aneesh Kumar K.V
2019-12-18 5:22 ` Aneesh Kumar K.V
2019-12-18 9:01 ` Peter Zijlstra
2019-12-18 9:01 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2019-12-17 7:16 Aneesh Kumar K.V
2019-12-17 7:16 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191217123544.GI2827@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.