Messages in this thread | | | Date | Wed, 2 Feb 2022 17:01:44 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/6] sched/preempt: refactor sched_dynamic_update() |
| |
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.
| |