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 A6F63C433EF for ; Wed, 2 Feb 2022 18:10:14 +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=3MaDL3PWzv0mVgUNXwawmXWkCLY47f4q8Z2rKEbb1xQ=; b=U13ji9mDHTRkhP /Et4LQiusC+9fzpdqenYLQX/rD2IrsC1/iybunK6GKGUnxaOwgPYAqZY1d5QoocgPB7gAZVhiPytp 3JAY1PnGelxGfkODGTupixQZgP0CZLW2fISpWsDMXDVVj9CgJzQaPedUAVp4ZX2uzs1pVlDl2mBfF 3MbWt966rGPd6WbkG943O+BW3vx+P72TQqAKUe1bzWuIM7ZDRg3fDJwjNXoC++atO/OxbWMi+LvDg y2P1VG1PKp+cku6SkXk2ANwwd6P4OQk31eDVcHlJ0XCc9jMUphtmyCx+eYUWib2syZaQfqC9Z9SnB +KYbGfuFTmv+qJ4TNsEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFK3i-00GWfn-KJ; Wed, 02 Feb 2022 18:08:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFK3d-00GWap-6U for linux-arm-kernel@lists.infradead.org; Wed, 02 Feb 2022 18:08:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 03FD8113E; Wed, 2 Feb 2022 10:08:33 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.87.240]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 731B03F40C; Wed, 2 Feb 2022 10:08:31 -0800 (PST) Date: Wed, 2 Feb 2022 18:08:27 +0000 From: Mark Rutland To: Frederic Weisbecker 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 2/6] sched/preempt: refactor sched_dynamic_update() Message-ID: References: <20211109172408.49641-1-mark.rutland@arm.com> <20211109172408.49641-3-mark.rutland@arm.com> <20211210151343.GA755274@lothringen> <20220202160144.GA458420@lothringen> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220202160144.GA458420@lothringen> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220202_100841_366992_1F4F6538 X-CRM114-Status: GOOD ( 33.92 ) 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 Wed, Feb 02, 2022 at 05:01:44PM +0100, Frederic Weisbecker wrote: > On Wed, Feb 02, 2022 at 03:13:57PM +0000, Mark Rutland wrote: > > Hi, > > > > I'm looking at what I need to do to rebase/repost this atop v5.17-rc2, and I > > realised I need your S-o-B to take your suggestion below. > > > > On Fri, Dec 10, 2021 at 04:13:43PM +0100, Frederic Weisbecker wrote: > > > On Tue, Nov 09, 2021 at 05:24:04PM +0000, Mark Rutland wrote: > > > > Currently sched_dynamic_update needs to open-code the enabled/disabled > > > > function names for each preemption model it supoprts, when in practice > > > > this is a boolean enabled/disabled state for each function. > > > > > > > > Make this clearer and avoid repetition by defining the enabled/disabled > > > > states at the function definition, and using helper macros to peform the > > > > static_call_update(). Where x86 currently overrides the enabled > > > > function, it is made to provide both the enabled and disabled states for > > > > consistency, with defaults provided by the core code otherwise. > > > > > > -#define __preempt_schedule_notrace_func preempt_schedule_notrace_thunk > > > > +#define preempt_schedule_notrace_dynamic_enabled preempt_schedule_notrace_thunk > > > > +#define preempt_schedule_notrace_dynamic_disabled NULL > > > > > > I'm worried about un-greppable macro definitions like this. > > I assume you mean that it's hard to go from: > > > > preempt_dynamic_enable(preempt_schedule_notrace); > > > > ... to this, because the `_dynamic_enabled` or `_dynamic_disabled` part gets > > token-pasted on? > > Right. Looking at this some more, I'm probably going to need to do token-pasting at some level no matter what we do, so how big of a concern is this? Searching for 'foo_function' should also find 'foo_function_dynamic_enabled' and 'foo_function_dynamic_disabled', and searching for either of those will find their original definition. If others aren't concerned, could we just live with that for now? > > The above will show up in a grep for `preempt_schedule_notrace`, but I agree > > it's not necessarily ideal, especially if grepping for an exact match. > > > > > Also this enable/disable switch look like a common pattern on static call so > > > how about moving that logic to static call itself? As in below (only > > > build-tested): > > > > Sure; if others also prefer that I'm more than happy to build atop. > > > > Can I have your Signed-off-by for that, or can you post that as its own patch? > > Sure, here is a better split and tested version here: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > static_call/toggle Thanks! > I was hoping to make a default backend based on static keys to implement these > toggeable static calls, but I had some issues on the way, although I can't > remember exactly which. > > So eventually I don't know if this stuff will be useful for you.... Having had a play with this, since you need to generate a wrapper for the static_key case, you either need to match the prototype or have a generic macro (and you likely end up back in token-pasting hell again anyhow). So as above, how much does this matter for now? > Well, I guess this can still ease a wrapper like: > > preempt_dynamic_enable(sym) > ---> CONFIG_STATIC_CALL=y? -----> static_call_enable(sym) > else > ---> CONFIG_STATIC_KEY=y? -----> static_key_enable(sym) In this series I just define preempt_dynamic_enable() dependent on CONFIG_STATIC_CALL or CONFIG_STATIC_KEY, which is functionally equivalent. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel