User: Password:
|
|
Subscribe / Log in / New account

Re: [PATCH tip/core/rcu] Reduce overhead of cond_resched() checks for RCU

From:  Dave Hansen <dave.hansen-AT-intel.com>
To:  paulmck-AT-linux.vnet.ibm.com
Subject:  Re: [PATCH tip/core/rcu] Reduce overhead of cond_resched() checks for RCU
Date:  Mon, 23 Jun 2014 16:30:12 -0700
Message-ID:  <53A8B884.6000600@intel.com>
Cc:  linux-kernel-AT-vger.kernel.org, mingo-AT-kernel.org, laijs-AT-cn.fujitsu.com, dipankar-AT-in.ibm.com, akpm-AT-linux-foundation.org, mathieu.desnoyers-AT-efficios.com, josh-AT-joshtriplett.org, tglx-AT-linutronix.de, peterz-AT-infradead.org, rostedt-AT-goodmis.org, dhowells-AT-redhat.com, edumazet-AT-google.com, dvhart-AT-linux.intel.com, fweisbec-AT-gmail.com, oleg-AT-redhat.com, ak-AT-linux.intel.com, cl-AT-gentwo.org, umgwanakikbuti-AT-gmail.com
Archive-link:  Article

On 06/23/2014 11:09 AM, Paul E. McKenney wrote:
> So let's see...  The open1 benchmark sits in a loop doing open()
> and close(), and probably spends most of its time in the kernel.
> It doesn't do much context switching.  I am guessing that you don't
> have CONFIG_NO_HZ_FULL=y, or the boot/sysfs parameter would not have
> much effect because then the first quiescent-state-forcing attempt would
> likely finish the grace period.
> 
> So, given that short grace periods help other workloads (I have the
> scars to prove it), and given that the patch fixes some real problems,

I'm not arguing that short grace periods _can_ help some workloads, or
that one is better than the other.  The patch in question changes
existing behavior by shortening grace periods.  This change of existing
behavior removes some of the benefits that my system gets out of RCU.  I
suspect this affects a lot more systems, but my core cout makes it
easier to see.

Perhaps I'm misunderstanding the original patch's intent, but it seemed
to me to be working around an overactive debug message.  While often a
_useful_ debug message, it was firing falsely in the case being
addressed in the patch.

> and given that the large number for rcutree.jiffies_till_sched_qs got
> us within 3%, shouldn't we consider this issue closed?

With the default value for the tunable, the regression is still solidly
over 10%.  I think we can have a reasonable argument about it once the
default delta is down to the small single digits.

One more thing I just realized: this isn't a scalability problem, at
least with rcutree.jiffies_till_sched_qs=12.  There's a pretty
consistent delta in throughput throughout the entire range of threads
from 1->160.  See the "processes" column in the data files:

plain 3.15:
> https://www.sr71.net/~dave/intel/willitscale/systems/bigb...
e552592e0383bc:
> https://www.sr71.net/~dave/intel/willitscale/systems/bigb...

or visually:

>
https://www.sr71.net/~dave/intel/array-join.html?1=willit...


(Log in to post comments)


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds