From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D5121C433EF for ; Thu, 3 Feb 2022 11:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X+c1dAOyS+Y8P3onA66n+Mbnowkskk+A5EnLbmUD39k=; b=bvEYxSAQ+MXw1C b8VbO3yRfw8l6dlz5+ylGhZ0FmTN6meZWnXzsKECA/SPk/FD5LvtOhRmJifJkYVuhpDSwpYvaOz+6 Rr2lvl8Bnp79/f2nMYNUf+0LXp92qd72FHE5lbmpynY4L+4dZTDtJavQdsJxhpKDME3cbw6SkpYcD a4hAcMGJI0M1iJIjcHmv2EtP03ZF+cxCutaPJpS1ED2zVUGnLmfRLASuVvOQ1Vd2he8/yqrbH0VUU GRX/t2xZsAlwy7uUpgZ0cr3o1WhAgIMu41ZudGAQvcX0Q+Y9lpfh3D8ZX2Xe6T0Xb8DMQ1j6+bPmg dEIm0rVPUVTY2N7H+K7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFaOD-0010TB-Uw; Thu, 03 Feb 2022 11:35:02 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFaO9-0010RN-42 for linux-arm-kernel@lists.infradead.org; Thu, 03 Feb 2022 11:34:58 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 486126156B; Thu, 3 Feb 2022 11:34:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C7BFC340E4; Thu, 3 Feb 2022 11:34:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643888095; bh=7keyY+IJy3RcFl5R8fQkbTOYl6e3YcZLJhUH+euqScA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rdKZ3Kxatocr3+jRIAgDzrN3zUB7EDa1zLk+ItzxO65+eG9ugd78qADd5LzMfbMX3 B/kf1UkkIOwSi2kJUCZnUqo1ULlEk3IgITSuiaoCCLw16ZnAN+IbY8Z+iEyvfIB6MU 2sPrDiz9R9bjrWdJtsYiZp9MvOG6BhLCBhBxJhLbCJthwWjy1R9RjHoYsEoK2H7W+7 eoWPgRaO4WC6U4CMBHyBjyKHVyLRqRKxn3XPKV3G/rjRqrTL+nBQu1AE7h1kKU/gXh dZFcAbhjOLKOY+yitkMqsv+B4sZEj84nQtTPlTI/Ld7PaM4ZGd922I81aewjuuEJ6B GrvFgPjhwYXRg== Date: Thu, 3 Feb 2022 12:34:53 +0100 From: Frederic Weisbecker To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, ardb@kernel.org, catalin.marinas@arm.com, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH 5/6] sched/preempt: add PREEMPT_DYNAMIC using static keys Message-ID: <20220203113453.GA471778@lothringen> References: <20211109172408.49641-1-mark.rutland@arm.com> <20211109172408.49641-6-mark.rutland@arm.com> <20220202232145.GA461279@lothringen> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220203_033457_279198_0415570A X-CRM114-Status: GOOD ( 21.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 03, 2022 at 09:51:46AM +0000, Mark Rutland wrote: > On Thu, Feb 03, 2022 at 12:21:45AM +0100, Frederic Weisbecker wrote: > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > > index 78c351e35fec..7710b6593c72 100644 > > > --- a/include/linux/sched.h > > > +++ b/include/linux/sched.h > > > @@ -2008,7 +2008,7 @@ static inline int test_tsk_need_resched(struct task_struct *tsk) > > > #if !defined(CONFIG_PREEMPTION) || defined(CONFIG_PREEMPT_DYNAMIC) > > > extern int __cond_resched(void); > > > > > > -#ifdef CONFIG_PREEMPT_DYNAMIC > > > +#if defined(CONFIG_PREEMPT_DYNAMIC) && defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) > > > > > > DECLARE_STATIC_CALL(cond_resched, __cond_resched); > > > > > > @@ -2017,6 +2017,14 @@ static __always_inline int _cond_resched(void) > > > return static_call_mod(cond_resched)(); > > > } > > > > > > +#elif defined(CONFIG_PREEMPT_DYNAMIC) && defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) > > > +extern int dynamic_cond_resched(void); > > > + > > > +static __always_inline int _cond_resched(void) > > > +{ > > > + return dynamic_cond_resched(); > > > > So in the end this is creating an indirect call for every preemption entrypoint. > > Huh? "indirect call" usually means a branch to a function pointer, and I don't > think that's what you mean here. Do you just mean that we add a (direct) > call+return? Right, basic terminology and me... > > This gets inlined, and will be just a direct call to dynamic_cond_resched(). > e,g. on arm64 this will be a single instruction: > > bl dynamic_cond_resched > > ... and (as the commit message desribes) then the implementation of > dynamic_cond_resched will be the same as the regular __cond_resched *but* the > static key trampoline is inlined at the start, e.g. > > | : > | bti c > | b > | mov w0, #0x0 // #0 > | ret > | mrs x0, sp_el0 > | ldr x0, [x0, #8] > | cbnz x0, > | paciasp > | stp x29, x30, [sp, #-16]! > | mov x29, sp > | bl > | mov w0, #0x1 // #1 > | ldp x29, x30, [sp], #16 > | autiasp > | ret > > ... compared to the regular form of the function: > > | <__cond_resched>: > | bti c > | mrs x0, sp_el0 > | ldr x1, [x0, #8] > | cbz x1, <__cond_resched+0x18> > | mov w0, #0x0 // #0 > | ret > | paciasp > | stp x29, x30, [sp, #-16]! > | mov x29, sp > | bl > | mov w0, #0x1 // #1 > | ldp x29, x30, [sp], #16 > | autiasp > | ret Who reads changelogs anyway? ;-) Ok I didn't know about that. Is this a guaranteed behaviour everywhere? Perhaps put a big fat comment below HAVE_PREEMPT_DYNAMIC_KEY help to tell about this expectation as I guess it depends on arch/compiler? Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel