Re: [PATCH tip/core/rcu 13/15] rcu: Introduce for_each_rcu_flavor()and use it

[Paul E. McKenney]

On Fri, Jun 15, 2012 at 10:35:00PM -0700, Josh Triplett wrote:
> On Fri, Jun 15, 2012 at 06:01:49PM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 15, 2012 at 04:52:40PM -0700, Josh Triplett wrote:
> > > On Fri, Jun 15, 2012 at 02:06:08PM -0700, Paul E. McKenney wrote:
> > > > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > > > index bd4e41c..75ad92a 100644
> > > > --- a/kernel/rcutree.c
> > > > +++ b/kernel/rcutree.c
> > > > @@ -84,6 +84,7 @@ struct rcu_state rcu_bh_state = RCU_STATE_INITIALIZER(rcu_bh, call_rcu_bh);
> > > >  DEFINE_PER_CPU(struct rcu_data, rcu_bh_data);
> > > >  
> > > >  static struct rcu_state *rcu_state;
> > > > +LIST_HEAD(rcu_struct_flavors);
> > > 
> > > Does any means exist to turn this into a constant array known at compile
> > > time rather than a runtime linked list?  Having this as a compile-time
> > > constant may allow the compiler to unroll for_each_rcu_flavor and
> > > potentially inline the calls inside it.
> > 
> > I could do that, but none of the traversals is anywhere near performance
> > critical, and all the ways I can think of to do this are uglier than
> > the list.
> 
> All of the struct rcu_state instances exist at compile time, so you can
> just create an array of pointers to them:
> 
> static struct rcu_state *const rcu_struct_flavors[] = {
>     &rcu_data,
>     &rcu_bh_data,
> #ifdef CONFIG_TREE_PREEMPT_RCU
>     &rcu_preempt_data,
> #endif
> };
> 
> Then just define for_each_rcu_flavor to iterate over that compile-time
> constant array.  Any reason that wouldn't work?

It could work, but I like the automated response of the current system.
Your array would add one more thing that would need to be manually
kept consistent.  Now, if any of the traversals were on a fastpath,
that would be different.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/