| 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
| ||
|
Message-Id: <20160713230404.GA2197@linux.vnet.ibm.com>
Date: Wed, 13 Jul 2016 16:04:04 -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 04:02:38PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 13, 2016 at 03:39:37PM -0700, John Stultz wrote:
> > On Wed, Jul 13, 2016 at 3:17 PM, Paul E. McKenney
> > <paulmck@...ux.vnet.ibm.com> wrote:
> > > 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.
> >
> > I think having it discoverable via menuconfig is useful, and I've got
> > no objections to it being under RCU_EXPERT
> > (assuming I don't badly muck up my RCU settings accidentally :).
>
> But isn't mucking up your RCU settings half of the fun? ;-)
>
> > I only had that one nit about maybe wanting to put something in dmesg
> > when we're using the expedited methods.
>
> Updated, please see below.
>
> > But otherwise both patches look great and are working well!
> >
> > Do you mind marking them both for stable 4.4+?
>
> OK, looks like it does qualify in the "fix a notable performance or
> interactivity issue" category.
>
> > Tested-by: John Stultz <john.stultz@...aro.org>
> > Acked-by: John Stultz <john.stultz@...aro.org>
> >
> > Also, do make sure Dmitry gets the reported-by credit for the first patch.
>
> Done! The updated first patch is below, and the second will follow.
As promised/threatened...
Thanx, Paul
------------------------------------------------------------------------
commit b4edebb8f5664a3a51be1e3ff3d7f1cb2d3d5c88
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>
Tested-by: John Stultz <john.stultz@...aro.org>
Acked-by: John Stultz <john.stultz@...aro.org>
Cc: <stable@...r.kernel.org> # 4.4.x-
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 0d0dc992cce7..cc75d5071543 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)
Powered by blists - more mailing lists