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: Thu, 3 Feb 2022 12:52:18 +0100 [thread overview]
Message-ID: <20220203115218.GB471778@lothringen> (raw)
In-Reply-To: <YfrImx6c4RuVuY7l@FVFF77S0Q05N>
On Wed, Feb 02, 2022 at 06:08:27PM +0000, Mark Rutland wrote:
> 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:
> > > > > +#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?
Sure, I don't have a better idea right now. I'll try to think of something
after the next iteration.
> > 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.
You're right.
It's just that instead of:
#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
#ifndef preempt_schedule_notrace_dynamic_enabled
#define preempt_schedule_notrace_dynamic_enabled preempt_schedule_notrace
#define preempt_schedule_notrace_dynamic_disabled NULL
#endif
#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
#define preempt_dynamic_enable(f) static_call_update(f, f##_dynamic_enabled)
#define preempt_dynamic_disable(f) static_call_update(f, #f##_dynamic_disabled)
You have:
DECLARE_STATIC_CALL_TOGGLE(preempt_schedule_notrace, __preempt_schedule_notrace_func);
#define preempt_dynamic_enable(f) static_call_enable(f)
#define preempt_dynamic_disable(f) static_call_disable(f)
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
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: Thu, 3 Feb 2022 12:52:18 +0100 [thread overview]
Message-ID: <20220203115218.GB471778@lothringen> (raw)
In-Reply-To: <YfrImx6c4RuVuY7l@FVFF77S0Q05N>
On Wed, Feb 02, 2022 at 06:08:27PM +0000, Mark Rutland wrote:
> 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:
> > > > > +#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?
Sure, I don't have a better idea right now. I'll try to think of something
after the next iteration.
> > 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.
You're right.
It's just that instead of:
#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
#ifndef preempt_schedule_notrace_dynamic_enabled
#define preempt_schedule_notrace_dynamic_enabled preempt_schedule_notrace
#define preempt_schedule_notrace_dynamic_disabled NULL
#endif
#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
#define preempt_dynamic_enable(f) static_call_update(f, f##_dynamic_enabled)
#define preempt_dynamic_disable(f) static_call_update(f, #f##_dynamic_disabled)
You have:
DECLARE_STATIC_CALL_TOGGLE(preempt_schedule_notrace, __preempt_schedule_notrace_func);
#define preempt_dynamic_enable(f) static_call_enable(f)
#define preempt_dynamic_disable(f) static_call_disable(f)
Thanks.
next prev parent reply other threads:[~2022-02-03 11:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 17:24 [PATCH 0/6] arm64 / sched/preempt: support PREEMPT_DYNAMIC with static keys Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-11-09 17:24 ` [PATCH 1/6] sched/preempt: move PREEMPT_DYNAMIC logic later Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-11-09 17:24 ` [PATCH 2/6] sched/preempt: refactor sched_dynamic_update() Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-12-10 15:13 ` Frederic Weisbecker
2021-12-10 15:13 ` Frederic Weisbecker
2022-02-02 15:13 ` Mark Rutland
2022-02-02 15:13 ` Mark Rutland
2022-02-02 16:01 ` Frederic Weisbecker
2022-02-02 16:01 ` Frederic Weisbecker
2022-02-02 18:08 ` Mark Rutland
2022-02-02 18:08 ` Mark Rutland
2022-02-03 11:52 ` Frederic Weisbecker [this message]
2022-02-03 11:52 ` Frederic Weisbecker
2021-11-09 17:24 ` [PATCH 3/6] sched/preempt: simplify irqentry_exit_cond_resched() callers Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-11-09 17:24 ` [PATCH 4/6] sched/preempt: decouple HAVE_PREEMPT_DYNAMIC from GENERIC_ENTRY Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-11-09 17:24 ` [PATCH 5/6] sched/preempt: add PREEMPT_DYNAMIC using static keys Mark Rutland
2021-11-09 17:24 ` Mark Rutland
2021-12-13 22:05 ` Frederic Weisbecker
2021-12-13 22:05 ` Frederic Weisbecker
2022-02-02 15:29 ` Mark Rutland
2022-02-02 15:29 ` Mark Rutland
2022-02-03 22:40 ` Peter Zijlstra
2022-02-03 22:40 ` Peter Zijlstra
2022-02-02 23:21 ` Frederic Weisbecker
2022-02-02 23:21 ` Frederic Weisbecker
2022-02-03 9:51 ` Mark Rutland
2022-02-03 9:51 ` Mark Rutland
2022-02-03 11:34 ` Frederic Weisbecker
2022-02-03 11:34 ` Frederic Weisbecker
2022-02-03 12:27 ` Mark Rutland
2022-02-03 12:27 ` Mark Rutland
2021-11-09 17:24 ` [PATCH 6/6] arm64: support PREEMPT_DYNAMIC Mark Rutland
2021-11-09 17:24 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220203115218.GB471778@lothringen \
--to=frederic@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.