Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946157AbbDXXLF (ORCPT ); Fri, 24 Apr 2015 19:11:05 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:35700 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965985AbbDXXLB convert rfc822-to-8bit (ORCPT ); Fri, 24 Apr 2015 19:11:01 -0400 Date: Sat, 25 Apr 2015 01:10:56 +0200 From: Hagen Paul Pfeifer To: "Paul E. McKenney" Cc: Andrew Morton , linux-kernel@vger.kernel.org, Ingo Molnar , "H. Peter Anvin" , "David S. Miller" , x86@kernel.org Subject: Re: [PATCH] enforce function inlining for hot functions Message-ID: <20150424231056.GA6321@virgo.local> References: <1429825201-2825-1-git-send-email-hagen@jauu.net> <20150424124905.07e29a3b1392513144cd1568@linux-foundation.org> <20150424201340.GD5561@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20150424201340.GD5561@linux.vnet.ibm.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2553 Lines: 64 * Paul E. McKenney | 2015-04-24 13:13:40 [-0700]: >Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the >above two would contain lockdep calls that might in some cases defeat >inlining. With the more typical production choice of PROVE_RCU=n, I would >expect these to just be a call instruction, which should get inlined. Ok, here are the results: with PROVE_RCU=y: rcu_read_lock: 383 duplicates with PROVE_RCU=n: rcu_read_lock: 114 duplicates If you look at the function anatomy of rcu_read_lock you often see the following definitions: : 55 push %rbp 48 89 e5 mov %rsp,%rbp 48 c7 c7 50 64 e7 85 mov $0xffffffff85e76450,%rdi e8 ce ff ff ff callq ffffffff816af206 5d pop %rbp c3 retq but sometimes rcu_read_lock looks: : 55 push %rbp 48 89 e5 mov %rsp,%rbp 50 push %rax 68 83 1e 1c 81 pushq $0xffffffff811c1e83 b9 02 00 00 00 mov $0x2,%ecx 31 d2 xor %edx,%edx 45 31 c9 xor %r9d,%r9d 45 31 c0 xor %r8d,%r8d 31 f6 xor %esi,%esi 48 c7 c7 50 64 e7 85 mov $0xffffffff85e76450,%rdi e8 86 4c f9 ff callq ffffffff81156b2e 5a pop %rdx 59 pop %rcx c9 leaveq c3 retq Means rcu_lock_acquire() is inlined here - but not in every compilation unit. Don't know exactly what forces gcc to inline not everywhere. Maybe register pressure in the function unit, or at least gcc is think that. I don't know. At the end you may notice that gcc inlining decisions are not always perfect and a little bit fuzzy (sure, they have their metric/scoring system). And sometimes the inlining should be enforced - as this patch do for some important functions. But as I said we should not enforce it everywhere, rather we should pray for better heuristics and let the compiler choose the best strategy (and incorporate -Os/-O2 decisions too). I think this is the best compromise here. Cheers, Hagen -- 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/