All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
	josh@joshtriplett.org, dvhltc@us.ibm.com, niv@us.ibm.com,
	tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org,
	Valdis.Kletnieks@vt.edu, dhowells@redhat.com
Subject: Re: [PATCH RFC tip/core/rcu] accelerate grace period if last non-dynticked CPU
Date: Wed, 27 Jan 2010 02:01:36 -0800	[thread overview]
Message-ID: <20100127100136.GM6807@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100127094336.GA12522@basil.fritz.box>

On Wed, Jan 27, 2010 at 10:43:36AM +0100, Andi Kleen wrote:
> On Tue, Jan 26, 2010 at 09:20:50PM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2010 at 10:30:57PM +0100, Andi Kleen wrote:
> > > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> > > 
> > > Kind of offtopic to the original patch, but I couldn't 
> > > resist...
> > > 
> > > > +config RCU_FAST_NO_HZ
> > > > +	bool "Accelerate last non-dyntick-idle CPU's grace periods"
> > > > +	depends on TREE_RCU && NO_HZ && SMP
> > > 
> > > Having such a thing as a config option doesn't really make 
> > > any sense to me. Who would want to recompile their kernel
> > > to enable/disable this? If anything it should be runtime, or better
> > > just unconditionally on.
> > 
> > It adds significant overhead on entry to dyntick-idle mode for systems
> > with large numbers of CPUs.  :-(
> 
> Can't you simply check that at runtime then?
> 
> if (num_possible_cpus() > 20) 
> 	...
> 
> BTW the new small is large. This years high end desktop PC will come with 
> upto 12 CPU threads. It would likely be challenging to find a good
> number for 20 that holds up with the future.

And this was another line of reasoning that lead me to the extra kernel
config parameter.

> Or better perhaps have some threshold that you don't do it 
> that often, or only do it when you expect to be idle for a long
> enough time that the CPU can enter deeper idle states
> 
> (I higher idle states some more wakeups typically don't matter
> that much)
> 
> The cpufreq/cstate governour have a reasonable good idea
> now how "idle" the system is and will be. Maybe you can reuse
> that information somehow.

My first thought was to find an existing "I am a small device running on
battery power" or "low power consumption is critical to me" config
parameter.  I didn't find anything that looked like that.  If there was
one, I would make RCU_FAST_NO_HZ depend on it.

Or did I miss some kernel parameter or API?

							Thanx, Paul

  parent reply	other threads:[~2010-01-27 10:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25  3:48 [PATCH RFC tip/core/rcu] accelerate grace period if last non-dynticked CPU Paul E. McKenney
2010-01-25 12:28 ` Lai Jiangshan
2010-01-25 12:35   ` Peter Zijlstra
2010-01-25 15:08   ` Steven Rostedt
2010-01-27  5:17   ` Paul E. McKenney
2010-01-25 15:12 ` Steven Rostedt
2010-01-27 14:11   ` Paul E. McKenney
2010-01-27 14:52     ` Steven Rostedt
2010-01-26 21:30 ` Andi Kleen
2010-01-26 23:55   ` Mathieu Desnoyers
2010-01-27  5:21     ` Paul E. McKenney
2010-01-27  5:20   ` Paul E. McKenney
2010-01-27  9:43     ` Andi Kleen
2010-01-27  9:50       ` Peter Zijlstra
2010-01-27 10:00         ` Andi Kleen
2010-01-27 10:04         ` Paul E. McKenney
2010-01-27 11:39           ` Nick Piggin
2010-01-27 11:59             ` Paul E. McKenney
2010-01-27 10:01       ` Paul E. McKenney [this message]
2010-01-27 10:13         ` Andi Kleen
2010-01-27 11:44           ` Paul E. McKenney
2010-01-27 12:11             ` Andi Kleen
2010-01-27 13:23               ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100127100136.GM6807@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.