From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756528AbZAHCRA (ORCPT ); Wed, 7 Jan 2009 21:17:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751368AbZAHCQw (ORCPT ); Wed, 7 Jan 2009 21:16:52 -0500 Received: from extu-mxob-1.symantec.com ([216.10.194.28]:45220 "EHLO extu-mxob-1.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751305AbZAHCQv (ORCPT ); Wed, 7 Jan 2009 21:16:51 -0500 Date: Thu, 8 Jan 2009 02:16:26 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.anvils To: Ingo Molnar cc: Andi Kleen , Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline In-Reply-To: <20090107131846.GF3529@elte.hu> Message-ID: References: <200901051236.281008835@firstfloor.org> <20090104233640.6A7453E6653@basil.firstfloor.org> <20090107131846.GF3529@elte.hu> 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 On Wed, 7 Jan 2009, Ingo Molnar wrote: > > > Hugh Dickins noticed that released gcc versions building the kernel with > > CONFIG_OPTIMIZE_INLINING=y don't inline some of the bitops - sometimes > > generating very inefficient pageflag tests, and many instances of > > constant_test_bit(). > > Could you quantify that please? > > We really dont want to reintroduce __always_inline just for performance / > code size reasons. If GCC messes up and makes a larger / more inefficient > kernel, GCC will be fixed. CONFIG_OPTIMIZE_INLINING is default-off, so > enable it only if it improves your kernel. I'm happy with the config option defaulting off, but the Kconfig help text seems too optimistic, and I doubt defconfigs should say Y yet. http://lkml.org/lkml/2008/11/14/203 CONFIG_OPTIMIZE_INLINING fun was my original mail to you on this: somewhat rambling, but worth looking at just for the laughable 4.2.1 Page disassemblies. Quantification: you may have a better idea of what numbers to look at, but here are some. I've tried "make defconfig" on 2.6.28 x86_32 kernel trees, building first with the openSUSE 10.3 version of gcc 4.2.1, then the openSUSE 11.1 version of gcc 4.3.2 (Fedora 10 and Ubuntu 8.10 versions gave similar results, though I didn't go very far with those), then the latest gcc 4.4 snapshot. I was building x86_64 a few weeks ago, and that gave similar results. I've built five configs: vmlinux.nn is the defconfig, except for CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_OPTIMIZE_INLINING both off; vmlinux.yn has SIZE=y, vmlinux.ny has INLINING=y, vmlinux.yy is the actual defconfig with both y, vmlinux.yya is that with Andi's bitops patch applied. For background I'm showing "size" output, and the number of lines in System.map (supposing that to give some idea of how much inlining). Then how many "Page" lines appear in System.map: ideally none, a few are okay, but lots mean it's being stupid about PageLocked etc - 4.2.1 SIZE=y INLINING=y is afflicted by that, the rest are okay. Then how many "constant_test_bit"s (each sized 27 bytes): clearly Andi's patch eliminates those. Contrary to expectations, 4.4 does little better than 4.3.2 with them; and though 4.2.1's yy case is worst, its ny case is actually much better than with 4.3 and 4.4 (or maybe there's a different interpretation than numbers suggest). I think these numbers show that that even gcc 4.4 is not yet ready for CONFIG_OPTIMIZE_INLINING=y, but that Andi's patch helps in one important area. grep for something else and maybe a different story. gcc version 4.2.1 (SUSE Linux): text data bss dec hex filename 6847905 1151180 622592 8621677 838e6d vmlinux.nn 45069 wc -l