Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753999Ab1EDOqm (ORCPT ); Wed, 4 May 2011 10:46:42 -0400 Received: from www.linutronix.de ([62.245.132.108]:45219 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752311Ab1EDOql (ORCPT ); Wed, 4 May 2011 10:46:41 -0400 Date: Wed, 4 May 2011 16:46:18 +0200 (CEST) From: Thomas Gleixner To: Tejun Heo cc: Pekka Enberg , Ingo Molnar , Linus Torvalds , Jens Axboe , Andrew Morton , werner , "H. Peter Anvin" , Linux Kernel Mailing List , Christoph Lameter Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs In-Reply-To: <20110504142532.GC17294@htj.dyndns.org> Message-ID: References: <20110504083559.GB25724@elte.hu> <20110504101932.GA3392@elte.hu> <20110504112746.GE8007@htj.dyndns.org> <20110504132022.GA17294@htj.dyndns.org> <20110504142532.GC17294@htj.dyndns.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1767 Lines: 57 On Wed, 4 May 2011, Tejun Heo wrote: > Hello, > > On Wed, May 04, 2011 at 04:10:29PM +0200, Thomas Gleixner wrote: > > > cases where the generic implementation is used. Has anyone measured > > > the difference against before the whole this_cpu conversion? > > > > Yes, that really wants to be done. The whole CMPXCHG_LOCAL ifdeffery > > should have been avoided in the first place. this_cpu_cmpxchg can > > really be implemented with preempt_enable/disable and the irqsafe > > variant in any case. > > Yeah, slub code looks pretty scary with the #ifdefs. IIUC, the > problem was that cmpxchg_double is an optimization for fast path which > was already very light weight and an extra locked op or irq on/off > would have made considerable difference. > > The cmpxchg_double optimization made the fast path go quite faster > when CPU supports it but it may as well slow things down considerably > if CPU doesn't, due to extra irq on/off's. Anyways, here's hoping Not really. CMPXCHG_LOCAL=n local_irq_save(); handle_everything(); local_irq_restore(); vs. CMPXCHG_LOCAL=y do_prep(); local_irq_save(); emulate_cmpxchg(); local_irq_restore(); do_rest(); So you have local irq disable/enable in both cases. So for the case where you don't have a local cmpxchg8b/16b available it's not worse versus irq disable/enable than now. It just has the possible repeat case when stuff changed between the prep and the actual cmpxchg, which is the same problem when cmpxchg8b/16 is available. Thanks, tglx -- 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/