linux-kernel - Re: [PATCH 1/1] rcu: Introduce CONFIG_RCU_EXP_CPU_STALL

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] [day] [month] [year] [list]

Message-ID: <Yg6LXv+XS85TXoEb@pc638.lan>
Date:   Thu, 17 Feb 2022 18:52:30 +0100
From:   Uladzislau Rezki <urezki@...il.com>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     "Uladzislau Rezki (Sony)" <urezki@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Axtens <dja@...ens.net>,
        Frederic Weisbecker <frederic@...nel.org>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>,
        Uladzislau Rezki <uladzislau.rezki@...y.com>
Subject: Re: [PATCH 1/1] rcu: Introduce CONFIG_RCU_EXP_CPU_STALL_TIMEOUT

On Wed, Feb 16, 2022 at 11:55:08AM -0800, Paul E. McKenney wrote:
> On Wed, Feb 16, 2022 at 02:52:09PM +0100, Uladzislau Rezki (Sony) wrote:
> > From: Uladzislau Rezki <uladzislau.rezki@...y.com>
> > 
> > Currently for both expedited and regular grace periods stall
> > warnings are emitted based on one timeout value that is defined
> > in seconds. The problem is that, a stall timeout in seconds for
> > expedited grace period is a way long.
> > 
> > The idea of expedited grace period is to force CPUs to report
> > their quiescent states as fast as possible. If in RCU read-side
> > critical section, it will request the next rcu_read_unlock() to
> > record the quiescent state. If not either it reports immediately
> > or set TIF_NEED_RESCHED to initiate the task switch.
> > 
> > Therefore introduce the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT kernel
> > configuration that is set to 20 msec. It also can be changed in
> > run-time via: /sys/.../parameters/rcu_exp_cpu_stall_timeout.
> > 
> > Signed-off-by: Uladzislau Rezki <uladzislau.rezki@...y.com>
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> 
> Nice, thank you!
> 
> I have queued this, with the usual wordsmithing.
> 
> I also changed the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT kconfig option's
> default to be 20 milliseconds only no CONFIG_ANDROID=y kernel builds.  For
> one, rcutorture gets expedited stall warnings even at 200 milliseconds,
> and for another, larger systems often have longer-running readers.
> It might be a very good thing to decrease the non-Android default
> expedited stall warning timeout, but 20 milliseconds is not likely the
> place to start that effort.  Though it would be one way to find out
> when in the process large-system users started testing.  ;-)
> 
> My guess is that this change will result in some breakage even on Android,
> and that adjustments will be needed.  Once that effort is complete,
> it would probably make sense to take another look at the non-Android
> default for CONFIG_RCU_EXP_CPU_STALL_TIMEOUT.
> 
Yep, totally agree. There will be needed an addition adjustment later on to
find some better floor value :) 

--
Vlad Rezki