From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751760AbdHBBBt (ORCPT <rfc822;w@1wt.eu>);
        Tue, 1 Aug 2017 21:01:49 -0400
Received: from gate.crashing.org ([63.228.1.57]:51828 "EHLO gate.crashing.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751029AbdHBBBs (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 1 Aug 2017 21:01:48 -0400
Message-ID: <1501633061.2792.137.camel@kernel.crashing.org>
Subject: Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>
Cc: 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 <mgorman@suse.de>,
        Rik van Riel <riel@redhat.com>
Date: Wed, 02 Aug 2017 10:17:41 +1000
In-Reply-To: <20170801164820.s46g2325kjjrymom@hirez.programming.kicks-ass.net>
References: <20170607161501.819948352@infradead.org>
         <20170607162013.705678923@infradead.org> <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>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2017-08-01 at 18:48 +0200, Peter Zijlstra wrote:
> On Tue, Aug 01, 2017 at 05:44:14PM +0100, Will Deacon wrote:
> > On Tue, Aug 01, 2017 at 06:39:03PM +0200, Peter Zijlstra wrote:
> > > Still this is all rather unsatisfactory. Either we should define
> > > flush_tlb*() to imply a barrier when its not a no-op (sparc64/ppc-hash)
> > > or simply make clear_tlb_flush_pending() an smp_store_release().
> > > 
> > > I prefer the latter option.
> > > 
> > > Opinions?
> > 
> > I prefer the latter option too, since I'd like to relax the arm64 TLB
> > flushing to have weaker barriers for the local case. Granted, that doesn't
> > break the NUMA migration code, but it would make the barrier semantics of
> > the TLB invalidation routines even more subtle if we were to define them
> > generally.
> 
> Another 'fun' question, is smp_mb() strong enough to order against the
> TLB invalidate? Because we really want to clear this flag _after_.
> 
> PowerPC for example uses PTESYNC before the TBLIE, so does a SYNC after
> work? Ben?

I have no idea. But then our tlbie has a ptesync after too no ? And
afaik a ptesync is a superset of sync.

Cheers,
Ben.