2024-02-28 19:41:27

by Paul E. McKenney

Subject: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
might see the occasional preemption, and that this preemption just might
happen within a trampoline.

Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks()
based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.

Only build tested.

Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Ankur Arora <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: <[email protected]>

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2da4eaa2777d6..c9e6c69cf3446 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3156,7 +3156,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
* synchronize_rcu_tasks() will wait for those tasks to
* execute and either schedule voluntarily or enter user space.
*/
- if (IS_ENABLED(CONFIG_PREEMPTION))
+ if (IS_ENABLED(CONFIG_TASKS_RCU))
synchronize_rcu_tasks();

ftrace_trampoline_free(ops);

2024-02-28 20:20:43

by Steven Rostedt

Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Wed, 28 Feb 2024 11:38:29 -0800
"Paul E. McKenney" <[email protected]> wrote:

> The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> might see the occasional preemption, and that this preemption just might
> happen within a trampoline.
>
> Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks()
> based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.
>
> Only build tested.
>
> Signed-off-by: Paul E. McKenney <[email protected]>
> Cc: Steven Rostedt <[email protected]>
> Cc: Masami Hiramatsu <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Mathieu Desnoyers <[email protected]>
> Cc: Ankur Arora <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: <[email protected]>
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 2da4eaa2777d6..c9e6c69cf3446 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -3156,7 +3156,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
> * synchronize_rcu_tasks() will wait for those tasks to
> * execute and either schedule voluntarily or enter user space.
> */
> - if (IS_ENABLED(CONFIG_PREEMPTION))
> + if (IS_ENABLED(CONFIG_TASKS_RCU))
> synchronize_rcu_tasks();

What happens if CONFIG_TASKS_RCU is not enabled? Does
synchronize_rcu_tasks() do anything? Or is it just a synchronize_rcu()?

If that's the case, perhaps just remove the if statement and make it:

synchronize_rcu_tasks();

Not sure an extra synchronize_rcu() will hurt (especially after doing a
synchronize_rcu_tasks_rude() just before hand!

-- Steve

2024-02-28 21:31:58

by Paul E. McKenney

Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> On Wed, 28 Feb 2024 11:38:29 -0800
> "Paul E. McKenney" <[email protected]> wrote:
>
> > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> > might see the occasional preemption, and that this preemption just might
> > happen within a trampoline.
> >
> > Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks()
> > based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.
> >
> > Only build tested.
> >
> > Signed-off-by: Paul E. McKenney <[email protected]>
> > Cc: Steven Rostedt <[email protected]>
> > Cc: Masami Hiramatsu <[email protected]>
> > Cc: Mark Rutland <[email protected]>
> > Cc: Mathieu Desnoyers <[email protected]>
> > Cc: Ankur Arora <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: <[email protected]>
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 2da4eaa2777d6..c9e6c69cf3446 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -3156,7 +3156,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
> > * synchronize_rcu_tasks() will wait for those tasks to
> > * execute and either schedule voluntarily or enter user space.
> > */
> > - if (IS_ENABLED(CONFIG_PREEMPTION))
> > + if (IS_ENABLED(CONFIG_TASKS_RCU))
> > synchronize_rcu_tasks();
>
> What happens if CONFIG_TASKS_RCU is not enabled? Does
> synchronize_rcu_tasks() do anything? Or is it just a synchronize_rcu()?

It is just a synchronize_rcu().

> If that's the case, perhaps just remove the if statement and make it:
>
> synchronize_rcu_tasks();
>
> Not sure an extra synchronize_rcu() will hurt (especially after doing a
> synchronize_rcu_tasks_rude() just before hand!

That would work for me. If there are no objections, I will make this
change.

Thanx, Paul

2024-03-01 20:25:18

by Paul E. McKenney

Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Wed, Feb 28, 2024 at 01:16:04PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> > On Wed, 28 Feb 2024 11:38:29 -0800
> > "Paul E. McKenney" <[email protected]> wrote:
> >
> > > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > > even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> > > might see the occasional preemption, and that this preemption just might
> > > happen within a trampoline.
> > >
> > > Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks()
> > > based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.
> > >
> > > Only build tested.
> > >
> > > Signed-off-by: Paul E. McKenney <[email protected]>
> > > Cc: Steven Rostedt <[email protected]>
> > > Cc: Masami Hiramatsu <[email protected]>
> > > Cc: Mark Rutland <[email protected]>
> > > Cc: Mathieu Desnoyers <[email protected]>
> > > Cc: Ankur Arora <[email protected]>
> > > Cc: Thomas Gleixner <[email protected]>
> > > Cc: <[email protected]>
> > >
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > > index 2da4eaa2777d6..c9e6c69cf3446 100644
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > > @@ -3156,7 +3156,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
> > > * synchronize_rcu_tasks() will wait for those tasks to
> > > * execute and either schedule voluntarily or enter user space.
> > > */
> > > - if (IS_ENABLED(CONFIG_PREEMPTION))
> > > + if (IS_ENABLED(CONFIG_TASKS_RCU))
> > > synchronize_rcu_tasks();
> >
> > What happens if CONFIG_TASKS_RCU is not enabled? Does
> > synchronize_rcu_tasks() do anything? Or is it just a synchronize_rcu()?
>
> It is just a synchronize_rcu().
>
> > If that's the case, perhaps just remove the if statement and make it:
> >
> > synchronize_rcu_tasks();
> >
> > Not sure an extra synchronize_rcu() will hurt (especially after doing a
> > synchronize_rcu_tasks_rude() just before hand!
>
> That would work for me. If there are no objections, I will make this
> change.

But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms)
and synchronize_rcu() (about 20ms). This is on a 80-hardware-thread
x86 system that is being flooded with calls to one or the other of
these two functions, but is otherwise idle. So adding that unnecessary
synchronize_rcu() adds about 20% to that synchronization delay.

Which might still be OK, but... In the immortal words of MS-DOS,
"Are you sure?". ;-)

Thanx, Paul

2024-03-01 20:28:39

by Steven Rostedt

Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Fri, 1 Mar 2024 12:25:10 -0800
"Paul E. McKenney" <[email protected]> wrote:

> > That would work for me. If there are no objections, I will make this
> > change.
>
> But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms)
> and synchronize_rcu() (about 20ms). This is on a 80-hardware-thread
> x86 system that is being flooded with calls to one or the other of
> these two functions, but is otherwise idle. So adding that unnecessary
> synchronize_rcu() adds about 20% to that synchronization delay.
>
> Which might still be OK, but... In the immortal words of MS-DOS,
> "Are you sure?". ;-)

It's just safe to keep it. It's definitely not a fast path.

-- Steve

2024-03-02 01:54:36

by Paul E. McKenney

Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Fri, Mar 01, 2024 at 03:30:01PM -0500, Steven Rostedt wrote:
> On Fri, 1 Mar 2024 12:25:10 -0800
> "Paul E. McKenney" <[email protected]> wrote:
>
> > > That would work for me. If there are no objections, I will make this
> > > change.
> >
> > But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms)
> > and synchronize_rcu() (about 20ms). This is on a 80-hardware-thread
> > x86 system that is being flooded with calls to one or the other of
> > these two functions, but is otherwise idle. So adding that unnecessary
> > synchronize_rcu() adds about 20% to that synchronization delay.
> >
> > Which might still be OK, but... In the immortal words of MS-DOS,
> > "Are you sure?". ;-)
>
> It's just safe to keep it. It's definitely not a fast path.

OK, you got it! ;-)

Thanx, Paul