From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752074AbdHBIL1 (ORCPT ); Wed, 2 Aug 2017 04:11:27 -0400 Received: from merlin.infradead.org ([205.233.59.134]:42766 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751121AbdHBIL0 (ORCPT ); Wed, 2 Aug 2017 04:11:26 -0400 Date: Wed, 2 Aug 2017 10:11:06 +0200 From: Peter Zijlstra To: Benjamin Herrenschmidt Cc: Will Deacon , torvalds@linux-foundation.org, oleg@redhat.com, paulmck@linux.vnet.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, linux-kernel@vger.kernel.org, mingo@kernel.org, stern@rowland.harvard.edu, Mel Gorman , Rik van Riel Subject: Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending() Message-ID: <20170802081106.kdl4grcb6sicqa3v@hirez.programming.kicks-ass.net> References: <20170609144553.GN13955@arm.com> <20170728174533.kbxu7uppdmle6t6d@hirez.programming.kicks-ass.net> <20170801103157.GD8702@arm.com> <1501588965.2792.121.camel@kernel.crashing.org> <20170801121419.a365inyyk5hghb6w@hirez.programming.kicks-ass.net> <20170801163903.wuwrk6ysyd52dwxm@hirez.programming.kicks-ass.net> <20170801164414.GB12027@arm.com> <20170801164820.s46g2325kjjrymom@hirez.programming.kicks-ass.net> <20170801225912.c23e6xave7qy5kzt@hirez.programming.kicks-ass.net> <1501636992.2792.139.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1501636992.2792.139.camel@kernel.crashing.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 02, 2017 at 11:23:12AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2017-08-02 at 00:59 +0200, Peter Zijlstra wrote: > > > PowerPC for example uses PTESYNC before the TBLIE, so does a SYNC after > > > work? Ben? > > > From what I gather it is not. You have TLBSYNC for it. So the good news > > tlbsync is pretty much a nop these days. ptesync is a strict superset > of sync and we have it after every tlbie. In the radix code, yes. I got lost going through the hash code, and I didn't look at the 32bit code at all. So the radix code does: PTESYNC TLBIE EIEIO; TLBSYNC; PTESYNC which should be completely ordered against anything prior and anything following, and is I think the behaviour we want from TLB flushes in general, but is very much not provided by a number of architectures afaict. Ah, found the hash-64 code, yes that's good too. The hash32 code lives in asm and confuses me, it has a bunch of SYNC, SYNC_601 and isync in. The nohash variant seems to do a isync after tlbwe, but again no clue. Now, do I go and attempt fixing all that needs fixing? x86 is good, our CR3 writes or INVLPG stuff is fully serializing. arm is good, it does DSB ISH before and after arm64 looks good too, although it plays silly games with the first barrier, but I trust that to be sufficient. But I'll have to go dig up arch manuals for the rest, if they include the relevant information at all of course :/