lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20161103162228.GG3716@linux.vnet.ibm.com>
Date:   Thu, 3 Nov 2016 09:22:28 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Julia Cartwright <julia@...com>,
        Luiz Capitulino <lcapitulino@...hat.com>,
        linux-rt-users@...r.kernel.org,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default

On Wed, Nov 02, 2016 at 05:30:02PM +0100, Sebastian Andrzej Siewior wrote:
> RCU_EXPEDITE_BOOT should speed up the boot process by enforcing
> synchronize_rcu_expedited() instead of synchronize_rcu() during the boot
> process. There should be no reason why one does not want this and there
> is no need worry about real time latency at this point.
> Therefore make it default.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

Well, it has been awhile since I removed a Kconfig parameter.

So why could this be a bad thing?

1.	Very large systems might see scalability issues with unconditional
	expediting at boot.  But if we don't try it, we won't know.

2.	People bringing up new hardware might not want quite so many
	IPIs.  But they can just set rcu_normal to prevent that.

I am therefore queuing it for testiong and review.  ;-)

							Thanx, Paul

> ---
> Checked on two boxes and synchronize_rcu() was invoked four times before
> it reached rcu_end_inkernel_boot()
> 
>  init/Kconfig        | 13 -------------
>  kernel/rcu/update.c |  6 ++----
>  2 files changed, 2 insertions(+), 17 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index b6c9166d878a..fe51bd3bbc61 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -771,19 +771,6 @@ config RCU_NOCB_CPU_ALL
> 
>  endchoice
> 
> -config RCU_EXPEDITE_BOOT
> -	bool
> -	default n
> -	help
> -	  This option enables expedited grace periods at boot time,
> -	  as if rcu_expedite_gp() had been invoked early in boot.
> -	  The corresponding rcu_unexpedite_gp() is invoked from
> -	  rcu_end_inkernel_boot(), which is intended to be invoked
> -	  at the end of the kernel-only boot sequence, just before
> -	  init is exec'ed.
> -
> -	  Accept the default if unsure.
> -
>  endmenu # "RCU Subsystem"
> 
>  config BUILD_BIN2C
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index b40d3468ba4e..419ca811bda9 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -130,8 +130,7 @@ bool rcu_gp_is_normal(void)
>  }
>  EXPORT_SYMBOL_GPL(rcu_gp_is_normal);
> 
> -static atomic_t rcu_expedited_nesting =
> -	ATOMIC_INIT(IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT) ? 1 : 0);
> +static atomic_t rcu_expedited_nesting = ATOMIC_INIT(1);
> 
>  /*
>   * Should normal grace-period primitives be expedited?  Intended for
> @@ -179,8 +178,7 @@ EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
>   */
>  void rcu_end_inkernel_boot(void)
>  {
> -	if (IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT))
> -		rcu_unexpedite_gp();
> +	rcu_unexpedite_gp();
>  	if (rcu_normal_after_boot)
>  		WRITE_ONCE(rcu_normal, 1);
>  }
> -- 
> 2.10.2
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ