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

[Mark Rutland]

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.