Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757AbbDUHmS (ORCPT ); Tue, 21 Apr 2015 03:42:18 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:33267 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751603AbbDUHmR (ORCPT ); Tue, 21 Apr 2015 03:42:17 -0400 Date: Tue, 21 Apr 2015 09:42:12 +0200 From: Ingo Molnar To: Hagen Paul Pfeifer , Linus Torvalds Cc: Borislav Petkov , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Andrew Morton Subject: Re: [PATCH RFC] x86: enforce inlining for atomics Message-ID: <20150421074212.GA25081@gmail.com> References: <1429565231-4609-1-git-send-email-hagen@jauu.net> <20150420215645.GC10191@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 1569 Lines: 45 * Hagen Paul Pfeifer wrote: > On 20 April 2015 at 23:56, Borislav Petkov wrote: > > > Hmm, that must be config-specific as doing > > > > objdump -D vmlinux | grep -i "atomic_add" > > > > here gives me only "drm_atomic_add_affected_connectors" matches. > > > > It probably gets inlined here always... > > Probably, the config is allyesconfig minus trace/kernel adress > sanitizer and gcov related options. So the thing is that allyesconfig turns on -Os: CONFIG_CC_OPTIMIZE_FOR_SIZE=y which is known to make bad decisions in other areas as well ... If -Os does such bad inlining decisions (and the inlining examples you cited are horrible!) then I guess a lot of the other 'inline' functions are handled by it badly as well. I'm not sure we should start fighting the compiler: if a compiler does not take 'inline' seriously then the solution is to use another compiler, or at least to use different compiler flags. If inlining decisions are bad even with saner compiler options then we can use __always_inline, and we actually do that for locking primitives and some other low level primitives: which are typically larger than atomics, so even reasonable compilers might uninline them. But I'm not against your patch either. Linus, what's your preference? Thanks, Ingo -- 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/