Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750954AbVL2UUQ (ORCPT ); Thu, 29 Dec 2005 15:20:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750958AbVL2UUQ (ORCPT ); Thu, 29 Dec 2005 15:20:16 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:710 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1750954AbVL2UUO (ORCPT ); Thu, 29 Dec 2005 15:20:14 -0500 Date: Thu, 29 Dec 2005 21:19:53 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Andrew Morton , arjan@infradead.org, linux-kernel@vger.kernel.org, mpm@selenic.com Subject: Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers Message-ID: <20051229201953.GA29546@elte.hu> References: <20051228114637.GA3003@elte.hu> <1135798495.2935.29.camel@laptopd505.fenrus.org> <20051228212313.GA4388@elte.hu> <20051228214845.GA7859@elte.hu> <20051228201150.b6cfca14.akpm@osdl.org> <20051229073259.GA20177@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -1.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.9 required=5.9 tests=ALL_TRUSTED,AWL autolearn=no SpamAssassin version=3.0.3 -2.8 ALL_TRUSTED Did not pass through any untrusted hosts 0.9 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1925 Lines: 43 * Linus Torvalds wrote: > > i think there's quite an attitude here - we are at the mercy of "gcc > > brainfarts" anyway, and users are at the mercy of "kernel brainfarts" > > just as much. > > There's a huge difference here. The gcc people very much have a "Oh, > we changed old documented behaviour - live with it" attitude, together > with "That was a gcc extension, not part of the C language, so when we > change how gcc behaves, it's _your_ problem" approach. > > At least they used to. yeah, i think that was definitely the case historically. > Maybe the right thing to do is to just heed that warning, and remove > such functions from header files and make them no-inline? That way we > get the size fixes _regardless_ of any compiler options. i think the eye-opener (for me at least) was that there's really a massive 5%+ size difference here, from 2 simple patches. And meanwhile Matt is doing truly hard size-reduction work and is mailing patches to lkml that remove 200-300 bytes of .text, which is 0.01% of code, apiece. Debloating is like scalability, a piece-by-piece process where we'll only see the full effects after doing 100 independent steps, but still we must not ignore the big effects either, nor must we get ourselves into losing maintainance battles. The current inline model seems to be a lost battle, the 'size noise' caused by spurious inlines (which count in the thousands) is _far_ outpowering most of the size reduction efforts. And i think it can be argued that at least in the -Os case gcc has a very clear directive wrt. what to do - and much less room to mess up. Independently of how much we trust it. Ingo - 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/