On Tue, Apr 14, 2015 at 08:19:57PM -0700, Linus Torvalds wrote:
> On Tue, Apr 14, 2015 at 7:55 PM, Paul E. McKenney
> <paul...@linux.vnet.ibm.com> wrote:
> >
> > Does the (currently being tested) patch below fix things up? If not,
> > please fill me in on the further error of my ways.
>
> Looks ok.
>
> That said, couldn't that last dummy gp_init_delay variable:
>
> > +/* Delay in jiffies for grace-period initialization delays, debug only. */
> > +#ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT
> > +static int gp_init_delay = CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY;
> > module_param(gp_init_delay, int, 0644);
> > +#else /* #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */
> > +static const int gp_init_delay;
> > +#endif /* #else #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */
>
> be just a
>
> #define gp_init_delay 0
>
> for the non-CONFIG_RCU_TORTURE_TEST_SLOW_INIT case, so that the code
> that then does
>
> + if (gp_init_delay > 0 &&
> + !(rsp->gpnum % (rcu_num_nodes * PER_RCU_NODE_PERIOD)))
>
> would just trivially compile away.
>
> I guess the compiler *might* see a 'static const int' that is never
> touched and realize it's always zero, but it's not obvious that will
> be the case.
Well, if I attempt to modify gp_init_delay in its const guise, for
example, using gp_init_delay++, I get the following:
/media/homes/git/linux-2.6-tip/kernel/rcu/tree.c: In function
‘rcu_gp_init’:
/media/homes/git/linux-2.6-tip/kernel/rcu/tree.c:1849:3: error:
increment of read-only variable ‘gp_init_delay’
make[2]: *** [kernel/rcu/tree.o] Error 1
make[1]: *** [kernel/rcu/tree.o] Error 2
make[1]: Leaving directory `/tmp/b'
make: *** [sub-make] Error 2
So the compiler knows that it cannot change. And if I compile with
CONFIG_RCU_TORTURE_TEST_SLOW_INIT=y, then:
$ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay
00000060 r __param_gp_init_delay
000000e3 r __param_str_gp_init_delay
00000444 d gp_init_delay
On the other hand, compiling with CONFIG_RCU_TORTURE_TEST_SLOW_INIT=n
results in:
$ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay
So the compiler isn't creating a variable in the const case.
>From what I can see, at -O1 or better, gcc optimizes the const variable
away. At -O0, gcc allocates space for it and actually tests it.
But if you prefer #define, not a problem.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
