Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753797AbbDYN0u (ORCPT ); Sat, 25 Apr 2015 09:26:50 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:33728 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbbDYN0t (ORCPT ); Sat, 25 Apr 2015 09:26:49 -0400 MIME-Version: 1.0 In-Reply-To: <20150425103141.GG5561@linux.vnet.ibm.com> References: <1429825201-2825-1-git-send-email-hagen@jauu.net> <20150424124905.07e29a3b1392513144cd1568@linux-foundation.org> <20150424201340.GD5561@linux.vnet.ibm.com> <20150424231056.GA6321@virgo.local> <20150425103141.GG5561@linux.vnet.ibm.com> Date: Sat, 25 Apr 2015 15:26:48 +0200 Message-ID: Subject: Re: [PATCH] enforce function inlining for hot functions From: Hagen Paul Pfeifer To: Paul McKenney , Markus Trippelsdorf Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Ingo Molnar , "H. Peter Anvin" , "David S. Miller" , x86@kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2423 Lines: 49 On 25 April 2015 at 12:31, Paul E. McKenney wrote: > I am not arguing either way on the wisdom or lack thereof of gcc's > inlining decisions. But PROVE_RCU=n and CONFIG_DEBUG_LOCK_ALLOC=n should > make rcu_read_lock() and rcu_read_unlock() both be empty functions in > a CONFIG_PREEMPT=n, which should hopefully trivialize gcc's inlining > decisions in that particular case. Hey Paul, yes, with DEBUG_LOCK_ALLOC disabled all rcu_read_lock and unlock functions are perfectly inlined. So now we have the following situation: depending on the gcc version and the particular kernel configuration some hot functions are not inlined - they are duplicated hundred times. Which is bad no matter how you consider gcc/kernel-configuration. I think this should *never* happened. With the patch we can make sure that hot functions are *always* inlined - no matter what gcc version and kernel configuration is used. Furthermore, as Markus already noted: compiled with -O2 this do not happened. Duplicates are only generated for -Os[1]. Ok, but now the question: should this happened for Os? I don't think so. I think we can do it better and mark these few functions as always inline. For the remaining inlined marked function we should provide gcc the flexibility and do not artificially enforce inlining. The current situation is bad: OPTIMIZE_INLINING is default no, which defacto enforces inlining for *all* inlined marked functions. GCC inlining mechanism is defacto disabled, which is also bad. Last but not least: the patch do not change anything for the current user, because we will still disable OPTIMIZE_INLINING (resulting in __always_inline for all inlined marked functions). The patch effects users who enable OPTIMIZE_INLINING and trust the compiler. Hagen PS: thank you Markus for the comment. [1] which is nonsense: the functions are not inlined yet, but are copied hundred times for "size optimized builds". gcc should rather redeclare the functions global, define it one time and call this function every time. But implementing such a scheme is probably a monster of itself and LTO is required so solve all issues with such a concept. -- 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/