From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751789AbdGZJgk (ORCPT ); Wed, 26 Jul 2017 05:36:40 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58130 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbdGZJgj (ORCPT ); Wed, 26 Jul 2017 05:36:39 -0400 Date: Wed, 26 Jul 2017 10:36:46 +0100 From: Will Deacon To: "Paul E. McKenney" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com Subject: Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option Message-ID: <20170726093645.GA2115@arm.com> References: <20170724215758.GA12075@linux.vnet.ibm.com> <1500933497-12612-4-git-send-email-paulmck@linux.vnet.ibm.com> <20170725163318.bporqvcoodtel4a6@hirez.programming.kicks-ass.net> <20170725164900.GR3730@linux.vnet.ibm.com> <20170725165957.alykngbnrrwn3onw@hirez.programming.kicks-ass.net> <20170725171701.GS3730@linux.vnet.ibm.com> <20170725185320.uis4hxqaqlx7y7gp@hirez.programming.kicks-ass.net> <20170725193612.GW3730@linux.vnet.ibm.com> <20170725202451.GC28975@worktop> <20170725211926.GA3730@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170725211926.GA3730@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote: > Some architectures are less precise than others in tracking which > CPUs are running a given process due to ASIDs, though this is > thought to be a non-problem: > > https://marc.info/?l=linux-arch&m=126716090413065&w=2 > https://marc.info/?l=linux-arch&m=126716262815202&w=2 > > Thoughts? On arm64, we *never* touch mm_cpumask, so it will always be empty. The only thing we could potentially use it for is non-broadcast TLB invalidation if the mm was only active on a single CPU, but when I implemented that we pretty much never hit that case. I was hoping fork()+exec() would trigger it (e.g. scripts), but the scheduler treats both of those as rebalancing points so the temporary ASID before the exec always has two CPUs set in its mask. Will