Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753241AbZAKM2V (ORCPT ); Sun, 11 Jan 2009 07:28:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751589AbZAKM2I (ORCPT ); Sun, 11 Jan 2009 07:28:08 -0500 Received: from casper.infradead.org ([85.118.1.10]:52001 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbZAKM2F (ORCPT ); Sun, 11 Jan 2009 07:28:05 -0500 Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning From: David Woodhouse To: Andi Kleen Cc: Andrew Morton , Ingo Molnar , Linus Torvalds , Harvey Harrison , "H. Peter Anvin" , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich In-Reply-To: <20090110030216.GW26290@one.firstfloor.org> References: <20090109204103.GA17212@elte.hu> <20090109213442.GA20051@elte.hu> <1231537320.5726.2.camel@brick> <20090109231227.GA25070@elte.hu> <20090110010125.GA31031@elte.hu> <20090109174158.096dee70.akpm@linux-foundation.org> <20090110030216.GW26290@one.firstfloor.org> Content-Type: text/plain Date: Sun, 11 Jan 2009 12:26:41 +0000 Message-Id: <1231676801.25018.150.camel@macbook.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-2.fc10) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2371 Lines: 53 On Sat, 2009-01-10 at 04:02 +0100, Andi Kleen wrote: > Long term that problem will hopefully disappear, as gcc learns to do cross > source file inlining (like a lot of other compilers already do) We've already been able to get GCC doing this for the kernel, in fact (the --combine -fwhole-program stuff I was working on a while back). It gives an interesting size reduction, especially in file systems and other places where we tend to have functions with a single call site... but in a different file. Linus argues that we don't want that kind of inlining because it harms debuggability, but that isn't _always_ true. Sometimes you weren't going to get a backtrace if something goes wrong _anyway_. And even if the size reduction doesn't necessarily give a corresponding performance improvement, we might not care. In the embedded world, size does matter too. And the numbers are such that you can happily keep debuginfo for the shipped kernel builds and postprocess any backtraces you get. Just as we can for distros. In general, I would much prefer being able to trust the compiler, rather than disabling its heuristics completely. We might not be able to trust it right now, but we should be working towards that state. Not just declaring that we know best, even though _sometimes_ we do. I think we should: - Unconditionally have 'inline' meaning 'always_inline'. If we say it, we should mean it. - Resist the temptation to use -fno-inline-functions. Allow GCC to inline other things if it wants to. - Reduce the number of unnecessary 'inline' markers, and have a policy that the use of 'inline' should be accompanied by either a GCC PR# or an explanation of why we couldn't reasonably have expected GCC to get this particular case right. - Have a similar policy of PR# or explanation for 'uninline' too. I don't think we should just give up on GCC ever getting it right. That way lies madness. As we've often found in the past. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- 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/