Received-SPF: pass (google.com: domain of linux-kernel+bounces-89077-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 1 Mar 2024 12:25:10 -0800
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Ankur Arora <ankur.a.arora@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>, kernel-team@meta.com
Subject: Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather
 than PREEMPTION
Message-ID: <2835d5ea-0396-49f6-88fb-be49cb998cc5@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <f6507b10-5bb5-4407-bd4d-c547193a5a28@paulmck-laptop>
 <20240228152236.7a4c9eec@gandalf.local.home>
 <b5acdc28-0441-49ca-9e8d-50d6ac40c395@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b5acdc28-0441-49ca-9e8d-50d6ac40c395@paulmck-laptop>

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" <paulmck@kernel.org> 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 <paulmck@kernel.org>
> > > Cc: Steven Rostedt <rostedt@goodmis.org>
> > > Cc: Masami Hiramatsu <mhiramat@kernel.org>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > > Cc: Ankur Arora <ankur.a.arora@oracle.com>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: <linux-trace-kernel@vger.kernel.org>
> > > 
> > > 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