Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5211905imb; Thu, 7 Mar 2019 10:09:07 -0800 (PST) X-Google-Smtp-Source: APXvYqyx2og8AYl/XXGbKyskUuHObwfk3y6dKUhQLyQqURQZbPJof6sgbT/81teQRL7sQKoarPwN X-Received: by 2002:a62:bd09:: with SMTP id a9mr13837328pff.61.1551982147078; Thu, 07 Mar 2019 10:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551982147; cv=none; d=google.com; s=arc-20160816; b=qRRynNxUfRpPdPe8AQSd1OADVXwGDRn94OtsnO8PF95h3ab+WGcZfzagamCr/pmc26 fvLSMiZlqhgjcVLyXzj/9uDyRJzJv4x+M1iSaxPUnjDbT6ivEZt/Vl0ZxbGvPoTy6HIQ ajoYtgc03/EoXRj1RKr41a3HmXJ6PDIViDLlyqIC3bRVKVNseGjsj243+y/9B0UJTstY YbW3CMP+twOC313pHaa0OtkmEEqPJiG/Fl2kKFvo3Y3MSAjZOtYInaMGTsxMQXienVru a79PUjSQI9zY8hUEB/a4UJIzguv5/KMtVVLqsZIUDb423Wea+CcC168LwXVzZt+12CSW mejA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=bbL4KWYI/bioyC16biKECIQd78u2BNwuK4rNrJxv//o=; b=iIoCLCd60gi6q2waN9xzaQhCYPwN8VUJdbDNfV4egCGLDG8fpModCjUhIGKgdxYiW1 0K+EzRu4TN0U2SwWQB0PpsflUxOnhHyS6/mR6YIXlDoNosrQ+6FGx1zE7iSgfDSNew/o HqD9F8b4HXSDNSMlewYhjm0yzgoztUKb3WRVF5QG9YoHW86lV0yKTHDAFm6J6/4mbXjk ZgJ6VbgQhcGyyptJlOjZSzauqstUJ1xIsQL6vp7pH0Dkjdifw4A7kW0YwKijUvzEoBgn z7k/FtWANo7aiHh4S6N6loAcXgyhC3Qe6ZVy/DNbb416wChEUL1KgDKe7jJ9yYy6w5wg eYwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=rEJZHtLr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h186si4219966pge.239.2019.03.07.10.08.51; Thu, 07 Mar 2019 10:09:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=rEJZHtLr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726311AbfCGSIT (ORCPT + 99 others); Thu, 7 Mar 2019 13:08:19 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:51396 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726180AbfCGSIS (ORCPT ); Thu, 7 Mar 2019 13:08:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bbL4KWYI/bioyC16biKECIQd78u2BNwuK4rNrJxv//o=; b=rEJZHtLrpeTtQncz5UdU+yU6d ETWl63KJxYK6Z/wRGhfovF1oAxkxgOv9XBPE1eTQ/8d2lKWjZDqce/XlpF71DD8L4kVx48beKfpU7 EhTo8esLs0mi1zmsTVQtIQwolj4z0fHm0PdTp3SNaqfPA3K85GzGjrLCj9RfPn9eiWykLNs2OPmSj mViLB6lKdH8G7vqTpSkXoIK2GAsmYHTjqnaKZQdGxG+X/SKQDwV0wwTUnRtIyP/Z/6w1LY3LG/Sqm Obxjf0Lwl0BCxQunTUQwLi+EaJDpphwSFv1+zPeTHkTLZdKU/swywb6LDUV1VCYibbV7YmAYclT2i RUhqKTkCQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:51646) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1h1xR5-0007TG-2w; Thu, 07 Mar 2019 18:08:03 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1h1xQy-00055n-RV; Thu, 07 Mar 2019 18:07:56 +0000 Date: Thu, 7 Mar 2019 18:07:56 +0000 From: Russell King - ARM Linux admin To: Joe Perches Cc: Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , Nick Desaulniers , Davidlohr Bueso , Elena Reshetova , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline' Message-ID: <20190307180756.z2omra6hhwobhwcc@shell.armlinux.org.uk> References: <20190307091514.2489338-1-arnd@arndb.de> <20190307172541.2262ccaxjk43twi4@shell.armlinux.org.uk> <1ad70fe88b2d22b2064c4ada53d3fb0bdacf6b66.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ad70fe88b2d22b2064c4ada53d3fb0bdacf6b66.camel@perches.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 07, 2019 at 09:42:40AM -0800, Joe Perches wrote: > On Thu, 2019-03-07 at 17:25 +0000, Russell King - ARM Linux admin wrote: > > On Thu, Mar 07, 2019 at 09:19:04AM -0800, Joe Perches wrote: > > > On Thu, 2019-03-07 at 10:14 +0100, Arnd Bergmann wrote: > > > > On 32-bit ARM, I got a link failure in futex_init() when building > > > > with clang in some random configurations: > > > > > > > > kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text' > > > > > > > > As far as I can tell, the problem is that a branch is over 16MB > > > > apart in those configurations, but only if it branches back to > > > > the init text. > > > > > > > > Marking the futex_detect_cmpxchg() function as noinline and > > > > not __init avoids the problem for me. > > > > > > Perhaps the __init and __exit #defines should be noinline > > > to allow discarding of the code. > > > > How does that help this case? > > It doesn't particularly. > It does help any other case that might arise. Please describe what "any other case" you are thinking of - as already stated, your patch would have no beneficial effect for the observed issue. In fact, it _could_ do exactly the opposite. Where functions can be inlined, they may become smaller due to no need for function prologue and epilogue, and other optimisations. Forcing the compiler to avoid inlining them could result in larger code, which means a higher chance of triggering the "relocation truncated to fit" problem. The converse is also a possibility too - it all depends on the inlining behaviour of the compiler towards static functions, and the resulting size of the code. What may be right for one architecture and compiler may not be right for another. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up