Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932748AbbELJpi (ORCPT ); Tue, 12 May 2015 05:45:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59415 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932503AbbELJpb (ORCPT ); Tue, 12 May 2015 05:45:31 -0400 Message-ID: <5551CB8B.6060007@redhat.com> Date: Tue, 12 May 2015 11:44:43 +0200 From: Denys Vlasenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Morton CC: Linus Torvalds , Thomas Graf , "David S. Miller" , Bart Van Assche , Peter Zijlstra , David Rientjes , Oleg Nesterov , "Paul E. McKenney" , Ingo Molnar , linux-kernel@vger.kernel.org, Hagen Paul Pfeifer Subject: Re: [PATCH] force inlining of spinlock ops References: <1431367042-31475-1-git-send-email-dvlasenk@redhat.com> <20150511151913.86c37cde9294700b4b0e26c4@linux-foundation.org> In-Reply-To: <20150511151913.86c37cde9294700b4b0e26c4@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3159 Lines: 74 On 05/12/2015 12:19 AM, Andrew Morton wrote: > On Mon, 11 May 2015 19:57:22 +0200 Denys Vlasenko wrote: > >> With both gcc 4.7.2 and 4.9.2, sometimes gcc mysteriously doesn't inline >> very small functions we expect to be inlined. In particular, >> with this config: http://busybox.net/~vda/kernel_config >> there are more than a thousand copies of tiny spinlock-related functions: >> >> $ nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn | grep ' spin' >> 473 000000000000000b t spin_unlock_irqrestore >> 292 000000000000000b t spin_unlock >> 215 000000000000000b t spin_lock >> 134 000000000000000b t spin_unlock_irq >> 130 000000000000000b t spin_unlock_bh >> 120 000000000000000b t spin_lock_irq >> 106 000000000000000b t spin_lock_bh >> >> Disassembly: >> >> ffffffff81004720 : >> ffffffff81004720: 55 push %rbp >> ffffffff81004721: 48 89 e5 mov %rsp,%rbp >> ffffffff81004724: e8 f8 4e e2 02 callq <_raw_spin_lock> >> ffffffff81004729: 5d pop %rbp >> ffffffff8100472a: c3 retq >> >> This patch fixes this via s/inline/__always_inline/ in spinlock.h. >> This decreases vmlinux by about 30k: >> >> text data bss dec hex filename >> 82375570 22255544 20627456 125258570 7774b4a vmlinux.before >> 82335059 22255416 20627456 125217931 776ac8b vmlinux > > See also https://lkml.org/lkml/2015/4/23/598 ("enforce function > inlining for hot functions"). > > Presumably Hagen didn't see the issue with spinlock functions. I > wonder why not. > > I suppose we should get both these consolidated into a coherent whole. > > It's a bit irritating to have to do this: presumably gcc will get fixed > and the huge sprinkling of __always_inline will become less and less > relevant over time and people will have trouble distinguishing "real > __always_inline which was put here for a purpose" from "dopey > __always_inline to work around a short-term gcc glitch". In my patches, I put __always_inline *only* on functions where my measurements show a large size decrease from doing so. *Not* on functions where "I think it may be a good idea". So far, all such functions were so trivial that inlining decision there is a no-brainer. > and then use inline_for_broken_gcc everywhere. That way, the reason > for the marker is self-explanatory and we can later hunt all these > things down and remvoe them. > > Also, the inline_for_broken_gcc definition can be made dependent on > particular gcc versions, which will allow us to easily keep an eye on > the behaviour of later gcc versions. I've seen it on gcc-4.7.2 and gcc-4.9.2, so this behavior is not limited to a narrow range of gcc versions. I'd say by now about half of running kernels can easily be affected. -- vda -- 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/