Re: [PATCH 2/6] sched/preempt: refactor sched_dynamic_update()

From: Frederic Weisbecker <frederic@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
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()
Date: Wed, 2 Feb 2022 17:01:44 +0100	[thread overview]
Message-ID: <20220202160144.GA458420@lothringen> (raw)
In-Reply-To: <YfqftfWSJfuH60Mi@FVFF77S0Q05N>

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.

> 
> 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

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....

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)

Thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel