|From:||Dave Hansen <dave.hansen-AT-intel.com>|
|Subject:||Re: [PATCH tip/core/rcu] Reduce overhead of cond_resched() checks for RCU|
|Date:||Mon, 23 Jun 2014 16:30:12 -0700|
|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|
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...
Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds