From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact Date: Fri, 9 Jan 2009 19:02:13 +0100 Message-ID: <20090109180213.GH26290@one.firstfloor.org> References: <20090109130057.GA31845@elte.hu> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Matthew Wilcox , "H. Peter Anvin" , Ingo Molnar , jim owens , Linus Torvalds , 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 To: Dirk Hohndel Return-path: In-Reply-To: <20090109094142.367012b6@infradead.org> List-ID: > I think that's the point. gcc will not get it right. I don't think that's necessary an universal truth. It can be probably fixed. > So we need to do it ourselves in the kernel sources. > We may not like it, but it's the only way to guarantee reproducable > reliable inline / noinline decisions. For most things we don't really need it to be reproducable, the main exception are the inlines in headers. Universal noinline would also be a bad idea because of its costs (4.1% text size increase). Perhaps should make it a CONFIG option for debugging though. -Andi > > /D > > -- > Dirk Hohndel > Intel Open Source Technology Center > -- ak@linux.intel.com