Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752893AbbEKWTS (ORCPT ); Mon, 11 May 2015 18:19:18 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39012 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbbEKWTP (ORCPT ); Mon, 11 May 2015 18:19:15 -0400 Date: Mon, 11 May 2015 15:19:13 -0700 From: Andrew Morton To: Denys Vlasenko 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 Message-Id: <20150511151913.86c37cde9294700b4b0e26c4@linux-foundation.org> In-Reply-To: <1431367042-31475-1-git-send-email-dvlasenk@redhat.com> References: <1431367042-31475-1-git-send-email-dvlasenk@redhat.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2944 Lines: 73 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". __always_inline is one of those things where a usage site should always be commented, because it's near impossible to work out why someone chose to use it. Quick, tell me what's happening in include/linux/slab.h. Perhaps we should do /* * Comment goes here. It is very specific about gcc versions. */ #define inline_for_broken_gcc __always_inline 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. -- 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/