linux-kernel - Re: [PATCH RFC v2] rcu: Add a minimum time for marking boot as completed

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: <20230227145544.GC2948950@paulmck-ThinkPad-P17-Gen-1>
Date:   Mon, 27 Feb 2023 06:55:44 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>, linux-kernel@...r.kernel.org,
        Frederic Weisbecker <frederic@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-doc@...r.kernel.org, rcu@...r.kernel.org
Subject: Re: [PATCH RFC v2] rcu: Add a minimum time for marking boot as
 completed

On Mon, Feb 27, 2023 at 08:22:06AM -0500, Joel Fernandes wrote:
> 
> 
> > On Feb 27, 2023, at 2:53 AM, Zhuo, Qiuxu <qiuxu.zhuo@...el.com> wrote:
> > 
> > 
> >> 
> >> From: Joel Fernandes (Google) <joel@...lfernandes.org>
> >> Sent: Saturday, February 25, 2023 11:34 AM
> >> To: linux-kernel@...r.kernel.org
> >> Cc: Joel Fernandes (Google) <joel@...lfernandes.org>; Frederic Weisbecker
> >> <frederic@...nel.org>; Lai Jiangshan <jiangshanlai@...il.com>; linux-
> >> doc@...r.kernel.org; Paul E. McKenney <paulmck@...nel.org>;
> >> rcu@...r.kernel.org
> >> Subject: [PATCH RFC v2] rcu: Add a minimum time for marking boot as
> >> completed
> >> 
> >> On many systems, a great deal of boot happens after the kernel thinks the
> >> boot has completed. It is difficult to determine if the system has really
> >> booted from the kernel side. Some features like lazy-RCU can risk slowing
> >> down boot time if, say, a callback has been added that the boot
> >> synchronously depends on.
> >> 
> >> Further, it is better to boot systems which pass 'rcu_normal_after_boot' to
> >> stay expedited for as long as the system is still booting.
> >> 
> >> For these reasons, this commit adds a config option
> >> 'CONFIG_RCU_BOOT_END_DELAY' and a boot parameter
> >> rcupdate.boot_end_delay.
> >> 
> >> By default, this value is 20s. A system designer can choose to specify a value
> >> here to keep RCU from marking boot completion.  The boot sequence will not
> >> be marked ended until at least boot_end_delay milliseconds have passed.
> > 
> > Hi Joel,
> > 
> > Just some thoughts on the default value of 20s, correct me if I'm wrong :-).
> > 
> > Does the OS with CONFIG_PREEMPT_RT=y kernel concern more about the 
> > real-time latency than the overall OS boot time?
> 
> But every system has to boot, even an RT system.
> 
> > 
> > If so, we might make rcupdate.boot_end_delay = 0 as the default value 
> > (NOT the default 20s) for CONFIG_PREEMPT_RT=y kernels? 
> 
> Could you measure how much time your RT system takes to boot before the application runs?
> 
> I can change it to default 0 essentially NOOPing it, but I would rather have a saner default (10 seconds even), than having someone forget to tune this for their system.

Provide a /sys location that the userspace code writes to when it
is ready?  Different systems with different hardware and software
configurations are going to take different amounts of time to boot,
correct?

								Thanx, Paul

> Thanks,
> 
>  - Joel
> 
> 
> > 
> > -Qiuxu
> > 
> >> Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> >> ---
> >> v1->v2:
> >>    Update some comments and description.
> >> ...
> >