Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754361AbZAITte (ORCPT ); Fri, 9 Jan 2009 14:49:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752072AbZAITtX (ORCPT ); Fri, 9 Jan 2009 14:49:23 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:55214 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbZAITtW (ORCPT ); Fri, 9 Jan 2009 14:49:22 -0500 Date: Fri, 9 Jan 2009 11:48:41 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Matthew Wilcox cc: Andi Kleen , Dirk Hohndel , "H. Peter Anvin" , Ingo Molnar , jim owens , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , jh@suse.cz Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact In-Reply-To: <20090109192918.GE6936@parisc-linux.org> Message-ID: References: <20090109084620.3c711aad@infradead.org> <20090109172011.GD26290@one.firstfloor.org> <20090109172801.GC6936@parisc-linux.org> <20090109174719.GG26290@one.firstfloor.org> <20090109094142.367012b6@infradead.org> <20090109180213.GH26290@one.firstfloor.org> <20090109185509.GJ26290@one.firstfloor.org> <20090109193506.GL26290@one.firstfloor.org> <20090109192918.GE6936@parisc-linux.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) 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: 1249 Lines: 30 On Fri, 9 Jan 2009, Matthew Wilcox wrote: > > Now, I'm not going to argue the directIO code is a shining example of > how we want things to look, but we don't really want ten arguments > being marshalled into a function call; we want gcc to inline the > direct_io_worker() and do its best to optimise the whole thing. Well, except we quite probably would be happier with gcc not doing that, than with gcc doing that too often. There are exceptions. If the caller is really small (ie a pure wrapper that perhaps just does some locking around the call), then sure, inlining a large function that only gets called from one place does make sense. But if both the caller and the callee is large, like in your example, then no. DON'T INLINE IT. Unless we _tell_ you, of course, which we probably shouldn't do. Why? Becuase debugging is more important. And deciding to inline that, you probably decided to inline something _else_ too. And now you've quite possibly blown your stackspace. Linus -- 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/