Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755227AbZAITBY (ORCPT ); Fri, 9 Jan 2009 14:01:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753277AbZAITBM (ORCPT ); Fri, 9 Jan 2009 14:01:12 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:48384 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753127AbZAITBK (ORCPT ); Fri, 9 Jan 2009 14:01:10 -0500 Date: Fri, 9 Jan 2009 11:00:00 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Andi Kleen cc: Dirk Hohndel , Matthew Wilcox , "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: <20090109185509.GJ26290@one.firstfloor.org> Message-ID: References: <49675920.4050205@hp.com> <20090109153508.GA4671@elte.hu> <49677CB1.3030701@zytor.com> <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> 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: 1031 Lines: 29 On Fri, 9 Jan 2009, Andi Kleen wrote: > > Ok you're saying we should pay the 4.1% by default for this? The thing is, YOU ARE MAKING THAT NUMBER UP! First off, the size increase only matters if it actually increases the cache footprint. And it may, but.. Secondly, my whole point here has been that we should not rely on gcc doing things behind our back, because gcc will generally do the wrong thing. If we decided to be more active about this, we could just choose to find the places that matter (in hot code) and fix _those_. Thirdly, you're just replacing _one_ random gcc choice with _another_ random one. What happens when you say -fno-inline-functions-called-once? Does it disable inlining for those functions IN GENERAL, or just for the LARGE ones? See? 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/