Messages in this thread | | | Date | Sun, 1 Jul 2012 05:52:22 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 01/22] rcu: Control RCU_FANOUT_LEAF from boot-time parameter |
| |
On Sun, Jul 01, 2012 at 12:17:58AM -0700, Josh Triplett wrote: > On Sun, Jul 01, 2012 at 03:49:42PM +0930, Rusty Russell wrote: > > On Fri, 22 Jun 2012 08:17:00 -0700, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> > > > > > > Although making RCU_FANOUT_LEAF a kernel configuration parameter rather > > > than a fixed constant makes it easier for people to decrease cache-miss > > > overhead for large systems, it is of little help for people who must > > > run a single pre-built kernel binary. > > > > > > This commit therefore allows the value of RCU_FANOUT_LEAF to be > > > increased (but not decreased!) via a boot-time parameter named > > > rcutree.rcu_fanout_leaf. > > ... > > > +static int rcu_fanout_leaf = CONFIG_RCU_FANOUT_LEAF; > > > +module_param(rcu_fanout_leaf, int, 0); > > > > Maybe it's overkill, but 0400 or 0444 might be a nice touch. > > I agree. 0 almost never makes sense; root should almost always have the > ability to read module parameters. And in this case, I see no reason > not to make it 0444.
Should I do the same for these parameters as well?
kernel/rcutree.c:module_param(blimit, int, 0); kernel/rcutree.c:module_param(qhimark, int, 0); kernel/rcutree.c:module_param(qlowmark, int, 0);
Cut-and-paste, it is a wonderful thing. ;-)
Thanx, Paul
| |