From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751773AbdHBPkm (ORCPT ); Wed, 2 Aug 2017 11:40:42 -0400 Received: from gate.crashing.org ([63.228.1.57]:60241 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbdHBPkl (ORCPT ); Wed, 2 Aug 2017 11:40:41 -0400 Message-ID: <1501682224.2792.153.camel@kernel.crashing.org> Subject: Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending() From: Benjamin Herrenschmidt To: Peter Zijlstra 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 Date: Wed, 02 Aug 2017 23:57:04 +1000 In-Reply-To: <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> <20170802081106.kdl4grcb6sicqa3v@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.4 (3.24.4-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-08-02 at 10:11 +0200, Peter Zijlstra wrote: > 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. Doing some archeology ? :-) In the hash32 days ptesync didn't exist, sync had all the needed semantics. tlbew isn't a proper invalidate per-se, but isync will flush the shadow TLBs, but I wouldn't bother too much about these, if needed I can go fix them. > 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 :/ Ben.