Messages in this thread | | | Date | Wed, 2 Feb 2022 18:08:27 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH 2/6] sched/preempt: refactor sched_dynamic_update() |
| |
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.
| |