From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751743AbbDOEM4 (ORCPT ); Wed, 15 Apr 2015 00:12:56 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:51311 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbbDOEMr (ORCPT ); Wed, 15 Apr 2015 00:12:47 -0400 Date: Tue, 14 Apr 2015 21:12:43 -0700 From: "Paul E. McKenney" To: Linus Torvalds Cc: Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Andrew Morton Subject: Re: [GIT PULL] RCU changes for v4.1 Message-ID: <20150415041243.GQ23685@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150413121407.GA1688@gmail.com> <20150415025528.GN23685@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15041504-0021-0000-0000-000009D83EA0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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