Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758836AbYFIX3c (ORCPT ); Mon, 9 Jun 2008 19:29:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754876AbYFIX3W (ORCPT ); Mon, 9 Jun 2008 19:29:22 -0400 Received: from ozlabs.org ([203.10.76.45]:35198 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754322AbYFIX3V (ORCPT ); Mon, 9 Jun 2008 19:29:21 -0400 From: Rusty Russell To: Christoph Lameter Subject: Re: [patch 04/41] cpu ops: Core piece for generic atomic per cpu operations Date: Tue, 10 Jun 2008 09:27:48 +1000 User-Agent: KMail/1.9.9 Cc: Mike Travis , Andrew Morton , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, David Miller , Eric Dumazet , Peter Zijlstra References: <20080530035620.587204923@sgi.com> <200806060959.13362.rusty@rustcorp.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806100927.48597.rusty@rustcorp.com.au> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1609 Lines: 39 On Tuesday 10 June 2008 05:00:36 Christoph Lameter wrote: > On Fri, 6 Jun 2008, Rusty Russell wrote: > > > Also, the above cpu_local_wrap(...) adds: > > > > > > #define cpu_local_wrap(l) \ > > > ({ \ > > > preempt_disable(); \ > > > (l); \ > > > preempt_enable(); \ > > > }) \ > > > > > > ... and there isn't a non-preemption version that I can find. > > > > Yes, this should be fixed. I thought i386 had optimized versions > > pre-merge, but I was wrong (%gs for per-cpu came later, and noone cleaned > > up these naive versions). Did you want me to write them? > > How can that be fixed? You have no atomic instruction that calculates the > per cpu address in one go. Huh? "incl %fs:varname" does exactly this. > And as long as that is the case you need to > disable preempt. Otherwise you may increment the per cpu variable of > another processor because the process was rescheduled after the address > was calculated but before the increment was done. But of course, that is not a problem. You make local_t an atomic_t, and then it doesn't matter which CPU you incremented. By definition if the caller cared, they would have had premption disabled. Hope that clarifies, Rusty. -- 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/