From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DEFADB7151 for ; Tue, 18 Jan 2011 07:43:41 +1100 (EST) Subject: Re: [PATCH] sched: provide scheduler_ipi() callback in response to smp_send_reschedule() From: Peter Zijlstra To: Benjamin Herrenschmidt In-Reply-To: <1295296310.2148.29.camel@pasglop> References: <1295262433.30950.53.camel@laptop> <1295296310.2148.29.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 21:43:03 +0100 Message-ID: <1295296983.30950.369.camel@laptop> Mime-Version: 1.0 Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org, linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, "H. Peter Anvin" , Heiko Carstens , Paul Mackerras , Helge Deller , sparclinux@vger.kernel.org, Linux-Arch , linux-s390@vger.kernel.org, Jesper Nilsson , Jeremy Fitzhardinge , Russell King , Hirokazu Takata , x86@kernel.org, "James E.J. Bottomley" , virtualization@lists.osdl.org, Ingo Molnar , Matt Turner , Fenghua Yu , Mike Frysinger , user-mode-linux-devel@lists.sourceforge.net, Konrad Rzeszutek Wilk , Jeff Dike , Chris Metcalf , xen-devel@lists.xensource.com, Mikael Starvik , linux-m32r@ml.linux-m32r.org, Ivan Kokshaysky , user-mode-linux-user@lists.sourceforge.net, uclinux-dist-devel@blackfin.uclinux.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Richard Henderson , Tony Luck , linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com, linux-am33-list@redhat.com, linux-kernel@vger.kernel.org, Ralf Baechle , Kyle McMartin , Paul Mundt , linux-alpha@vger.kernel.org, Martin Schwidefsky , linux390@de.ibm.com, Koichi Yasutake , linuxppc-dev@lists.ozlabs.org, "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2011-01-18 at 07:31 +1100, Benjamin Herrenschmidt wrote: >=20 > Beware of false positive, I've used "fake" reschedule IPIs in the past > for other things (like kicking a CPU out of sleep state for unrelated > reasons). Nothing that I know that is upstream today but some of that > might come back. I'd like to avoid having to add an atomic to know if > it's a real reschedule, will the scheduler be smart enough to not bother > with false positives ?=20 Yes it can deal with that, some will be for reschedules, some will be for ttwu tail ends and x86 too uses this ipi for a few random other things like kicking kvm out of guest context..