Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753691AbZAIQ2V (ORCPT ); Fri, 9 Jan 2009 11:28:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752139AbZAIQ2G (ORCPT ); Fri, 9 Jan 2009 11:28:06 -0500 Received: from terminus.zytor.com ([198.137.202.10]:58897 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751441AbZAIQ2E (ORCPT ); Fri, 9 Jan 2009 11:28:04 -0500 Message-ID: <49677A0E.3090709@zytor.com> Date: Fri, 09 Jan 2009 08:23:42 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Linus Torvalds CC: Ingo Molnar , Andi Kleen , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning References: <1231408718.11687.400.camel@twins> <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <20090108190038.GH496@one.firstfloor.org> <4966AB74.2090104@zytor.com> <20090109133710.GB31845@elte.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1192 Lines: 35 Linus Torvalds wrote: > > On Fri, 9 Jan 2009, Ingo Molnar wrote: >> >> -static inline int constant_test_bit(int nr, const volatile unsigned long *addr) >> +static __asm_inline int >> +constant_test_bit(int nr, const volatile unsigned long *addr) >> { >> return ((1UL << (nr % BITS_PER_LONG)) & >> (((unsigned long *)addr)[nr / BITS_PER_LONG])) != 0; > > Thios makes absolutely no sense. > > It's called "__always_inline", not __asm_inline. > > Why add a new nonsensical annotations like that? > __asm_inline was my suggestion, to distinguish "inline this unconditionally because gcc screws up in the presence of asm()" versus "inline this unconditionally because the world ends if it isn't" -- to tell the human reader, not gcc. I guess the above is a good indicator that the __asm_inline might have been a bad name. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/