lkml.org 
[lkml]   [2016]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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@linux.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@linux.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@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.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)
\
 
 \ /
  Last update: 2016-07-14 01:01    [W:0.155 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site