linux-kernel - Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

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: <20160713221750.GR7094@linux.vnet.ibm.com>
Date:	Wed, 13 Jul 2016 15:17:50 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Tejun Heo <tj@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Dmitry Shmidt <dimitrysh@...gle.com>,
	Rom Lemarchand <romlem@...gle.com>,
	Colin Cross <ccross@...gle.com>, Todd Kjos <tkjos@...gle.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Severe performance regression w/ 4.4+ on Android due to cgroup
 locking changes

On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote:
> On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote:
> >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote:
> >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote:
> >> > > Take the patch that I just sent out and make the choice of normal
> >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are
> >> > > calling it these days.  Is there a low-latency Kconfig option other
> >> > > than CONFIG_NO_HZ_FULL?
> >> >
> >> > Sounds like a plan to me.
> >>
> >> I like the way we like each other's idea.  Mutually assured laziness?  ;-)
> >
> > But here is what mine might look like.  Untested, probably does
> > not even build.  Note that the default is -no- expediting, use the
> > rcusync.expedited kernel parameter to enable it.
> 
> I was working on something similar, but using a config option. Would
> adding a config option for the default make sense here, since I'd
> probably prefer to have one less thing to always specify on the
> cmdline?

As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem.

Perhaps like the following, on top of the previous patch?

Or if you are going to put it in defconfig files only, I can make it
so that it isn't changeable at menuconfig time.

							Thanx, Paul

------------------------------------------------------------------------

commit 57d8274b6906fad135a74beb59d4a99552659686
Author: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Date:   Wed Jul 13 15:13:31 2016 -0700

    rcu: Provide RCUSYNC_EXPEDITE option for rcusync.expedited default
    
    This commit provides an RCUSYNC_EXPEDITE Kconfig option that specifies
    the default value for the rcusync.expedited kernel parameter.  This
    makes it easier to use rcusync.expedited functionality in cases where
    specifying kernel boot parameters should be avoided.
    
    Reported-by: John Stultz <john.stultz@...aro.org>
    Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>

diff --git a/init/Kconfig b/init/Kconfig
index a068265fbcaf..de548d6ff82b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -782,6 +782,23 @@ config RCU_EXPEDITE_BOOT
 
 	  Accept the default if unsure.
 
+config RCUSYNC_EXPEDITE
+	bool "Expedite rcusync operations for per-CPU rwsems"
+	depends on RCU_EXPERT
+	default n
+	help
+	  Use this option to speed up per-CPU rwsem operations that are
+	  in turn used by some cgroups operations.  However, note well
+	  that specifying this option will enable expedited RCU grace
+	  periods.  These expedited grace periods can in turn introduce
+	  OS jitter, which can interfere with real-time, low-latency,
+	  HPC, and userspace-polling RDMA workloads.  That said, this
+	  OS jitter will not affect CPUs that are in nohz_full mode for
+	  the duration of the per-CPU rwsem operation in question.
+
+	  Say Y here if you want fast cgroups at the expense of OS jitter.
+	  Say N here if you are unsure.
+
 endmenu # "RCU Subsystem"
 
 config BUILD_BIN2C
diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
index 5bc5bef2e00a..58c594b41d48 100644
--- a/kernel/rcu/sync.c
+++ b/kernel/rcu/sync.c
@@ -70,7 +70,7 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY };
 
 #define	rss_lock	gp_wait.lock
 
-static bool expedited;
+static bool expedited = IS_ENABLED(CONFIG_RCUSYNC_EXPEDITE);
 module_param(expedited, bool, 0444);
 
 static int __init rcu_sync_early_init(void)