[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200219164449.GC2935@paulmck-ThinkPad-P72>
Date: Wed, 19 Feb 2020 08:44:50 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, mingo@...nel.org,
joel@...lfernandes.org, gregkh@...uxfoundation.org,
gustavo@...eddedor.com, tglx@...utronix.de, josh@...htriplett.org,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
luto@...nel.org, tony.luck@...el.com, frederic@...nel.org,
dan.carpenter@...cle.com, mhiramat@...nel.org
Subject: Re: [PATCH v3 08/22] rcu,tracing: Create trace_rcu_{enter,exit}()
On Wed, Feb 19, 2020 at 05:35:35PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 19, 2020 at 11:15:32AM -0500, Steven Rostedt wrote:
> > On Wed, 19 Feb 2020 16:58:28 +0100
> > Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > > On Wed, Feb 19, 2020 at 10:49:03AM -0500, Steven Rostedt wrote:
> > > > On Wed, 19 Feb 2020 15:47:32 +0100
> > > > Peter Zijlstra <peterz@...radead.org> wrote:
> > >
> > > > > These helpers are macros because of header-hell; they're placed here
> > > > > because of the proximity to nmi_{enter,exit{().
> > >
> > > ^^^^
> >
> > Bah I can't read, because I even went looking for this!
> >
> > >
> > > > > +#define trace_rcu_enter() \
> > > > > +({ \
> > > > > + unsigned long state = 0; \
> > > > > + if (!rcu_is_watching()) { \
> > > > > + rcu_irq_enter_irqsave(); \
> > > > > + state = 1; \
> > > > > + } \
> > > > > + state; \
> > > > > +})
> > > > > +
> > > > > +#define trace_rcu_exit(state) \
> > > > > +do { \
> > > > > + if (state) \
> > > > > + rcu_irq_exit_irqsave(); \
> > > > > +} while (0)
> > > > > +
> > > >
> > > > Is there a reason that these can't be static __always_inline functions?
> > >
> > > It can be done, but then we need fwd declarations of those RCU functions
> > > somewhere outside of rcupdate.h. It's all a bit of a mess.
> >
> > Maybe this belongs in the rcupdate.h file then?
>
> Possibly, and I suppose the current version is less obviously dependent
> on the in_nmi() functionality as was the previous, seeing how Paul
> frobbed that all the way into the rcu_irq_enter*() implementation.
>
> So sure, I can go move it I suppose.
No objections here.
Thanx, Paul
Powered by blists - more mailing lists