From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218Ab0AKWJu (ORCPT ); Mon, 11 Jan 2010 17:09:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751992Ab0AKWJt (ORCPT ); Mon, 11 Jan 2010 17:09:49 -0500 Received: from tomts36.bellnexxia.net ([209.226.175.93]:49611 "EHLO tomts36-srv.bellnexxia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449Ab0AKWJt (ORCPT ); Mon, 11 Jan 2010 17:09:49 -0500 Date: Mon, 11 Jan 2010 17:04:46 -0500 From: Mathieu Desnoyers To: Peter Zijlstra Cc: "Paul E. McKenney" , Steven Rostedt , Oleg Nesterov , linux-kernel@vger.kernel.org, Ingo Molnar , akpm@linux-foundation.org, josh@joshtriplett.org, tglx@linutronix.de, Valdis.Kletnieks@vt.edu, dhowells@redhat.com, laijs@cn.fujitsu.com, dipankar@in.ibm.com, "David S. Miller" Subject: Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (v3a) Message-ID: <20100111220446.GA14937@Krystal> References: <20100110052508.GG9044@linux.vnet.ibm.com> <1263124209.28171.3798.camel@gandalf.stny.rr.com> <20100110174512.GH9044@linux.vnet.ibm.com> <20100110182423.GA22821@Krystal> <20100111011705.GJ9044@linux.vnet.ibm.com> <20100111042521.GB32213@Krystal> <20100111042903.GC32213@Krystal> <1263232240.4244.70.camel@laptop> <20100111205250.GA6866@Krystal> <1263244757.4244.75.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <1263244757.4244.75.camel@laptop> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 16:59:00 up 26 days, 6:17, 4 users, load average: 0.00, 0.09, 0.10 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra (peterz@infradead.org) wrote: > On Mon, 2010-01-11 at 15:52 -0500, Mathieu Desnoyers wrote: > > > > So the clear bit can occur far, far away in the future, we don't care. > > We'll just send extra IPIs when unneeded in this time-frame. > > I think we should try harder not to disturb CPUs, particularly in the > face of RT tasks and DoS scenarios. Therefore I don't think we should > just wildly send to mm_cpumask(), but verify (although speculatively) > that the remote tasks' mm matches ours. > Well, my point of view is that if IPI TLB shootdown does not care about disturbing CPUs running other processes in the time window of the lazy removal, why should we ? We're adding an overhead very close to that of an unrequired IPI shootdown which returns immediately without doing anything. The tradeoff here seems to be: - more overhead within switch_mm() for more precise mm_cpumask. vs - lazy removal of the cpumask, which implies that some processors running a different process can receive the IPI for nothing. I really doubt we could create an IPI DoS based on such a small time window. Thanks, Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68