Re: [PATCH RFC v6 4/5] tracepoint: Make rcuidle tracepoint callers use SRCU
From: Joel Fernandes
Date: Mon May 07 2018 - 17:45:22 EST
On Mon, May 07, 2018 at 02:08:01PM -0700, Paul E. McKenney wrote:
> On Mon, May 07, 2018 at 01:41:42PM -0700, Joel Fernandes wrote:
> > From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
> >
> > In recent tests with IRQ on/off tracepoints, a large performance
> > overhead ~10% is noticed when running hackbench. This is root caused to
> > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
> > tracepoint code. Following a long discussion on the list [1] about this,
> > we concluded that srcu is a better alternative for use during rcu idle.
> > Although it does involve extra barriers, its lighter than the sched-rcu
> > version which has to do additional RCU calls to notify RCU idle about
> > entry into RCU sections.
> >
> > In this patch, we change the underlying implementation of the
> > trace_*_rcuidle API to use SRCU. This has shown to improve performance
> > alot for the high frequency irq enable/disable tracepoints.
[...]
>> Signed-off-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx>
> > ---
> > include/linux/tracepoint.h | 46 +++++++++++++++++++++++++++++++-------
> > kernel/tracepoint.c | 15 ++++++++++++-
> > 2 files changed, 52 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> > index c94f466d57ef..f56f290cf8eb 100644
> > --- a/include/linux/tracepoint.h
> > +++ b/include/linux/tracepoint.h
> > @@ -15,6 +15,7 @@
> > */
> >
> > #include <linux/smp.h>
> > +#include <linux/srcu.h>
> > #include <linux/errno.h>
> > #include <linux/types.h>
> > #include <linux/cpumask.h>
> > @@ -33,6 +34,8 @@ struct trace_eval_map {
> >
> > #define TRACEPOINT_DEFAULT_PRIO 10
> >
> > +extern struct srcu_struct tracepoint_srcu;
> > +
> > extern int
> > tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
> > extern int
> > @@ -77,6 +80,9 @@ int unregister_tracepoint_module_notifier(struct notifier_block *nb)
> > */
> > static inline void tracepoint_synchronize_unregister(void)
> > {
> > +#ifdef CONFIG_TRACEPOINTS
> > + synchronize_srcu(&tracepoint_srcu);
> > +#endif
> > synchronize_sched();
> > }
> >
> > @@ -129,18 +135,38 @@ extern void syscall_unregfunc(void);
> > * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
> > * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto".
> > */
> > -#define __DO_TRACE(tp, proto, args, cond, rcucheck) \
> > +#define __DO_TRACE(tp, proto, args, cond, rcuidle) \
> > do { \
> > struct tracepoint_func *it_func_ptr; \
> > void *it_func; \
> > void *__data; \
> > + int __maybe_unused idx = 0; \
> > \
> > if (!(cond)) \
> > return; \
> > - if (rcucheck) \
> > - rcu_irq_enter_irqson(); \
> > - rcu_read_lock_sched_notrace(); \
> > - it_func_ptr = rcu_dereference_sched((tp)->funcs); \
> > + \
> > + /* \
> > + * For rcuidle callers, use srcu since sched-rcu \
> > + * doesn't work from the idle path. \
> > + */ \
> > + if (rcuidle) { \
> > + if (in_nmi()) { \
> > + WARN_ON_ONCE(1); \
> > + return; /* no srcu from nmi */ \
> > + } \
> > + \
> > + idx = srcu_read_lock_notrace(&tracepoint_srcu); \
> > + it_func_ptr = \
> > + srcu_dereference_notrace((tp)->funcs, \
> > + &tracepoint_srcu); \
> > + /* To keep it consistent with !rcuidle path */ \
> > + preempt_disable_notrace(); \
> > + } else { \
> > + rcu_read_lock_sched_notrace(); \
> > + it_func_ptr = \
> > + rcu_dereference_sched((tp)->funcs); \
> > + } \
> > + \
> > if (it_func_ptr) { \
> > do { \
> > it_func = (it_func_ptr)->func; \
> > @@ -148,9 +174,13 @@ extern void syscall_unregfunc(void);
> > ((void(*)(proto))(it_func))(args); \
> > } while ((++it_func_ptr)->func); \
> > } \
> > - rcu_read_unlock_sched_notrace(); \
> > - if (rcucheck) \
> > - rcu_irq_exit_irqson(); \
> > + \
> > + if (rcuidle) { \
>
> Don't we also need an in_nmi() check here in order to avoid unbalanced
> srcu_read_unlock_notrace() calls?
The in_nmi() in the lock path should take care of making sure its balanced.
The diff the way its formatted appears confusing as Mathieu pointed.
thanks,
- Joel