Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758067AbZA2SMH (ORCPT ); Thu, 29 Jan 2009 13:12:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753528AbZA2SLy (ORCPT ); Thu, 29 Jan 2009 13:11:54 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:56582 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753524AbZA2SLx (ORCPT ); Thu, 29 Jan 2009 13:11:53 -0500 Date: Thu, 29 Jan 2009 13:11:52 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Linus Torvalds cc: Peter Zijlstra , Andrew Morton , LKML , Rusty Russell , npiggin@suse.de, Ingo Molnar , Thomas Gleixner , Arjan van de Ven , jens.axboe@oracle.com Subject: Re: [PATCH -v2] use per cpu data for single cpu ipi calls In-Reply-To: Message-ID: References: <200901290955.38940.rusty@rustcorp.com.au> <20090128173039.cbc29e81.akpm@linux-foundation.org> <1233218954.7835.11.camel@twins> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1339 Lines: 43 On Thu, 29 Jan 2009, Linus Torvalds wrote: > > > On Thu, 29 Jan 2009, Steven Rostedt wrote: > > > > Actually, we are locking against the destination CPU. > > Oh. > > THAT'S JUST INCOMPETENT. Or lack of sleep ;-) > > What the *fuck* is the point of having per-CPU data, and then using it for > the wrong CPU? > > Stop doing that idiocy. Put the per-cpu data on the senders side, and stop > the idiocy. You are going to get cross-CPU cacheline bouncing anyway, > there's no way to avoid it, but as long as you do it on the wrong CPU's > local data, you're missing the whole POINT of having per-cpu data in the > first place. > > But yeah, that explains the locking. One stupid design mistake leads to > another. > > And are you really sure it cannot be called from within interrupts? I'm > finding a lot of callers of smp_call_function_single(), and while I > couldn't find any that look like interrupts, I also couldn't find any > indication that it never happens. No, the solution that Peter gave on top of mine looks like something we can all be happy with. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/