From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751228AbdGZHrN (ORCPT ); Wed, 26 Jul 2017 03:47:13 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:56655 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750813AbdGZHrM (ORCPT ); Wed, 26 Jul 2017 03:47:12 -0400 Date: Wed, 26 Jul 2017 09:46:56 +0200 From: Peter Zijlstra To: Mathieu Desnoyers Cc: "Paul E. McKenney" , linux-kernel , Ingo Molnar , Lai Jiangshan , dipankar , Andrew Morton , Josh Triplett , Thomas Gleixner , rostedt , David Howells , Eric Dumazet , fweisbec , Oleg Nesterov , Will Deacon Subject: Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option Message-ID: <20170726074656.obadfdu6hdlrmy7r@hirez.programming.kicks-ass.net> References: <20170724215758.GA12075@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> <20170725215510.GD28975@worktop> <1480480872.25829.1501023013862.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1480480872.25829.1501023013862.JavaMail.zimbra@efficios.com> 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 Tue, Jul 25, 2017 at 10:50:13PM +0000, Mathieu Desnoyers wrote: > This would implement a MEMBARRIER_CMD_PRIVATE_EXPEDITED (or such) flag > for expedited process-local effect. This differs from the "SHARED" flag, > since the SHARED flag affects threads accessing memory mappings shared > across processes as well. > > I wonder if we could create a MEMBARRIER_CMD_SHARED_EXPEDITED behavior > by iterating on all memory mappings mapped into the current process, > and build a cpumask based on the union of all mm masks encountered ? > Then we could send the IPI to all cpus belonging to that cpumask. Or > am I missing something obvious ? I would readily object to such a beast. You far too quickly end up having to IPI everybody because of some stupid shared map or something (yes I know, normal DSOs are mapped private). The whole private_expedited is only palatable because we can only hinder our own threads (much).