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 S1751834AbdHAQoR (ORCPT <rfc822;w@1wt.eu>);
        Tue, 1 Aug 2017 12:44:17 -0400
Received: from foss.arm.com ([217.140.101.70]:43270 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751631AbdHAQoQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 1 Aug 2017 12:44:16 -0400
Date: Tue, 1 Aug 2017 17:44:14 +0100
From: Will Deacon <will.deacon@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        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>
Subject: Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()
Message-ID: <20170801164414.GB12027@arm.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170801163903.wuwrk6ysyd52dwxm@hirez.programming.kicks-ass.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Will