Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1156714ybl; Fri, 10 Jan 2020 13:09:25 -0800 (PST) X-Google-Smtp-Source: APXvYqwT/oyiQBVMN9Ls75Lb06vp58xQvxUVIgSwyKnVKcfFqq7UUa5FlKZDuvVJxJ4OkBTXl+x8 X-Received: by 2002:a9d:3b5:: with SMTP id f50mr4090911otf.354.1578690565756; Fri, 10 Jan 2020 13:09:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578690565; cv=none; d=google.com; s=arc-20160816; b=c7px2o2eufXk4EQPFRnihgby2ND78e5QhK0QhManTgpuM2xfa5GX06JqiUb3kzltlg MlPmUW0bJZObGm0UW9k3vNhH8uEye0PaA1Jkwrw4wso1aSA9je3GpIEG0uIx749VrKuX 219HsGg7WKA5yggIbqS5dRLaY8daCOcDvj6bqX69XEMeoF8Uxtu/MHk5FAvO5ij2BM4b FaXGoFRJrQzFfxX1udKaSiSoutFJZLwqHEinBV8yHywjkio7PD0HrMDdjV8aSULj8I06 BRrOAqX/dBIb9I0Koo0YO9ZSXklcF2dT0lUqrXMKQwM6rKUHaktitVO2VAG0TiHvhjHC JGng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=sOoOqB1veSTcfvJ22FSRghdZIFT5o5dQ0httJ786tQE=; b=MCFBSnM5L6hVHf+ng10KvDPmYFg79MfnuErP8ckrUTTAw7kwR3myRc2OxRtOq7XhNz sJScD1FK/Ug7Z1Rd5n8XyAWf1vIh3VM/NmXzXHaRdgvB9lVVu76lW3EqWKX419MxLzP1 V85tnhV7EP71S6Fzev9aqU0GXu1CNzq78z6G29JQTRs+8K6HmJd9vmKpdVCiwjo6b1jv PZz5bnM7c3MfUAuPTOK3Q83yk27HX6GQ6rTkSaGqnlKPklgz+85ZWgxlHTZTNnw9cp13 v/m/ZWXCh9nkAGjSrYf4xl+UHQlMMKjq/VlWGQxyixpty/B1qYSz1PSiOJQlfz8Ylc6O DeJQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1si1646584oic.140.2020.01.10.13.09.13; Fri, 10 Jan 2020 13:09:25 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727191AbgAJVIC (ORCPT + 99 others); Fri, 10 Jan 2020 16:08:02 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:59790 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726842AbgAJVIB (ORCPT ); Fri, 10 Jan 2020 16:08:01 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iq1VU-0004ld-Ub; Fri, 10 Jan 2020 22:07:49 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 6009B105BDB; Fri, 10 Jan 2020 22:07:48 +0100 (CET) From: Thomas Gleixner To: Arnd Bergmann , Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Vincenzo Frascino , Andy Lutomirski , "linux-kernel\@vger.kernel.org" , linuxppc-dev , Linux ARM , "open list\:BROADCOM NVRAM DRIVER" , the arch/x86 maintainers Subject: Re: [RFC PATCH v2 05/10] lib: vdso: inline do_hres() In-Reply-To: References: Date: Fri, 10 Jan 2020 22:07:48 +0100 Message-ID: <87o8vbrpej.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann writes: > On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy > wrote: >> >> do_hres() is called from several places, so GCC doesn't inline >> it at first. >> >> do_hres() takes a struct __kernel_timespec * parameter for >> passing the result. In the 32 bits case, this parameter corresponds >> to a local var in the caller. In order to provide a pointer >> to this structure, the caller has to put it in its stack and >> do_hres() has to write the result in the stack. This is suboptimal, >> especially on RISC processor like powerpc. >> >> By making GCC inline the function, the struct __kernel_timespec >> remains a local var using registers, avoiding the need to write and >> read stack. >> >> The improvement is significant on powerpc. >> >> Signed-off-by: Christophe Leroy > > Good idea, I can see how this ends up being an improvement > for most of the callers. > > Acked-by: Arnd Bergmann https://lore.kernel.org/r/20191112012724.250792-3-dima@arista.com On the way to be applied. Thanks, tglx