Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6888697ybe; Wed, 18 Sep 2019 10:40:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqykX3aNI/NuutyVWNPaP6yWTAR6vcHlhRIHnuWNem89qcOX6kC7MnzEnxsNJ9JZYOm5zXhj X-Received: by 2002:a17:907:4242:: with SMTP id np2mr10748434ejb.102.1568828412324; Wed, 18 Sep 2019 10:40:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568828412; cv=none; d=google.com; s=arc-20160816; b=nVUJHV9q5mF0AlyCgSASBMqyrkyp8vG2oQV9jqmVH4pXK/i2Kp0e2fQ96TN682CCtL bZI4PyTPW0jSR4B1niE5LKKt4TXK3vsRoDkcWI84OdxzMBugrIusjC4jmHHeSwQhTjOi AFQxIM8Lw/v8Km0K9XCfp1P6BWT/FxH4cN1MxxaswL4GbDEJBc0PurfIxKxrebh4RmSI lXyLcvffOJKc1yC8Zh4/0noT0gDKr/OhEmO3OknxrIZW94VSvfWYcE/RzwH1e5fLXbGa R/QN1O9Pj34vIncEDCniR+yzkJ8lvdSBGWJAnoan7vtsFZ0BGDBdF88Jw5Ixx284jjl0 Zbrw== 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; bh=6s/Y/QxzbOOrkNscCAkMnhUX2wJLf/TPsWCKdA8dcqE=; b=lTaY/l+IWAuQPMhbrBLS8NMeNZTD2dcdj+79Puvg6QadawqBbrXvas2s8SWsk/HO1H evrV6HzXHWRwSpFugbIkAraDXK7PKpVyT9SyeEo9kkOB8D17vLpLd2o6XdtaGUecbbD2 50fQ84BAGxnNhn4Rj5BFOxLV+nBqkGN2+MSuiFmkfXjP5IOE7NJ1WLsJPEKX2zJaz7O8 C9Yr4FjixH/enylkqS3/qhtSoVzrXDSLveVsSFoy/pjf1B1EyCi0UMNDYnd3viuxuQKr 3zLtl5bgmbzpiwiJXFBPo5lV3wbj6whMRVS31zSfwTgDTK/g4uApdYO2rbSbVfCIkbYy X18g== 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 r10si3714456edh.358.2019.09.18.10.39.48; Wed, 18 Sep 2019 10:40:12 -0700 (PDT) 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 S2387660AbfIRQjr (ORCPT + 99 others); Wed, 18 Sep 2019 12:39:47 -0400 Received: from gate.crashing.org ([63.228.1.57]:60564 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727100AbfIRQjr (ORCPT ); Wed, 18 Sep 2019 12:39:47 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x8IGdKX3020595; Wed, 18 Sep 2019 11:39:20 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x8IGdJjs020591; Wed, 18 Sep 2019 11:39:19 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 18 Sep 2019 11:39:19 -0500 From: Segher Boessenkool To: Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , npiggin@gmail.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() Message-ID: <20190918163919.GH9749@gate.crashing.org> References: <5fb4aedadbd28b9849cf2fabe13392fb3b5cd3ed.1568821668.git.christophe.leroy@c-s.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fb4aedadbd28b9849cf2fabe13392fb3b5cd3ed.1568821668.git.christophe.leroy@c-s.fr> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christophe, On Wed, Sep 18, 2019 at 03:48:20PM +0000, Christophe Leroy wrote: > call_do_irq() and call_do_softirq() are quite similar on PPC32 and > PPC64 and are simple enough to be worth inlining. > > Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. But you hardcode the calling sequence in inline asm, which for various reasons is not a great idea. > +static inline void call_do_irq(struct pt_regs *regs, void *sp) > +{ > + register unsigned long r3 asm("r3") = (unsigned long)regs; > + > + asm volatile( > + " "PPC_STLU" 1, %2(%1);\n" > + " mr 1, %1;\n" > + " bl %3;\n" > + " "PPC_LL" 1, 0(1);\n" : "+r"(r3) : > + "b"(sp), "i"(THREAD_SIZE - STACK_FRAME_OVERHEAD), "i"(__do_irq) : > + "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6", "cr7", > + "r0", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12"); > +} I realise the original code had this... Loading the old stack pointer value back from the stack creates a bottleneck (via the store->load forwarding it requires). It could just use addi 1,1,-(%2) here, which can also be written as addi 1,1,%n2 (that is portable to all architectures btw). Please write the "+r"(r3) on the next line? Not on the same line as the multi-line template. This make things more readable. I don't know if using functions as an "i" works properly... It probably does, it's just not something that you see often :-) What about r2? Various ABIs handle that differently. This might make it impossible to share implementation between 32-bit and 64-bit for this. But we could add it to the clobber list worst case, that will always work. So anyway, it looks to me like it will work. Nice cleanup. Would be better if you could do the call to __do_irq from C code, but maybe we cannot have everything ;-) Reviewed-by: Segher Boessenkool Segher