[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160617174621.GX3923@linux.vnet.ibm.com>
Date: Fri, 17 Jun 2016 10:46:21 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Pranith Kumar <bobby.prani@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>, jiangshanlai@...il.com,
Dipankar Sarma <dipankar@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Josh Triplett <josh@...htriplett.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
David Howells <dhowells@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Darren Hart <dvhart@...ux.intel.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH tip/core/rcu 04/12] rcu: Move expedited code from tree.c
to tree_exp.h
On Fri, Jun 17, 2016 at 11:48:12AM -0400, Pranith Kumar wrote:
> Hi Paul,
>
> On Wed, Jun 15, 2016 at 5:46 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> > People have been having some difficulty finding their way around the
> > RCU code. This commit therefore pulls some of the expedited grace-period
> > code from tree.c to a new tree_exp.h file. This commit is strictly code
> > movement, with the exception of a forward declaration that was added
> > for the sync_sched_exp_online_cleanup() function.
> >
> > A subsequent commit will move the remaining expedited grace-period code
> > from tree_plugin.h to tree_exp.h.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > ---
> > kernel/rcu/tree.c | 545 +-----------------------------------------------
> > kernel/rcu/tree_exp.h | 564 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 566 insertions(+), 543 deletions(-)
> > create mode 100644 kernel/rcu/tree_exp.h
> >
>
> I've always wondered why you chose to only have a header file instead
> of the traditional x.h/x.c split for declarations and
> definitions(looking at tree_plugin.h). Is there any particular reason
> for this?
I didn't want to worry about function-call overhead, and doing it this
way allowed inlining. Perhaps if link-time optimizations end up being
used heavily, I should go to the usual .h/.c split.
Thanx, Paul
Powered by blists - more mailing lists