All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Dominik Brodowski <linux@dominikbrodowski.net>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Dmitry Torokhov <dtor@mail.ru>
Subject: Re: A few questions and issues with dynticks, NOHZ and powertop
Date: Sun, 4 Apr 2010 16:37:02 -0700	[thread overview]
Message-ID: <20100404233702.GA24102@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100404204725.GC2644@linux.vnet.ibm.com>

On Sun, Apr 04, 2010 at 01:47:25PM -0700, Paul E. McKenney wrote:
> On Sun, Apr 04, 2010 at 06:39:24PM +0200, Dominik Brodowski wrote:
> > On Sun, Apr 04, 2010 at 11:17:37AM -0400, Alan Stern wrote:
> > > On Sun, 4 Apr 2010, Dominik Brodowski wrote:
> > > 
> > > > Booting a SMP-capable kernel with "nosmp", or manually offlining one CPU
> > > > (or -- though I haven't tested it -- booting a SMP-capable kernel on a
> > > > system with merely one CPU) means that in up to about half of the calls to
> > > > tick_nohz_stop_sched_tick() are aborted due to rcu_needs_cpu(). This is
> > > > quite strange to me: AFAIK, RCU is an excellent tool for SMP, but not really
> > > > needed for UP?
> > > 
> > > I can't answer the real question here, not knowing enough about the RCU
> > > implementation.  However, your impression is wrong: RCU very definitely
> > > _is_ useful and needed on UP systems.  It coordinates among processes
> > > (and interrupt handlers) as well as among processors.
> > 
> > Okay, but still: can't this be sped up by much on UP (especially if
> > CONFIG_RCU_FAST_NO_HZ is set), so that we can go to sleep right away?
> 
> One situation that will prevent CONFIG_RCU_FAST_NO_HZ from putting the
> machine to sleep right away is if there is an RCU callback posted that
> spawns another RCU callback, and so on.  CONFIG_RCU_FAST_NO_HZ will handle
> one callback that spawns another, but it gives up if the second callback
> spawns a third.
> 
> Might this be what is happening to you?
> 
> If so, would you be willing to patch your kernel?  RCU_NEEDS_CPU_FLUSHES
> is currently set to 5, and might be set to (say) 8.  This is defined
> in kernel/rcutree_plugin.h, near line 990.
> 
> Another thing to try would be running with TINY_RCU, at least if it is
> OK that RCU be non-preemptible.

And you did mention offlining some CPUs above.  The folloiwng patch
(from Lai Jiangshan) is needed to handle this case.

							Thanx, Paul

------------------------------------------------------------------------

commit 6a2ae79877827355b747c0b91133a963b74ed396
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Tue Mar 30 18:40:36 2010 +0800

    rcu: ignore offline CPUs in last non-dyntick-idle CPU check
    
    Offline CPUs are not in nohz_cpu_mask, but can be ignored when checking
    for the last non-dyntick-idle CPU.  This patch therefore only checks
    online CPUs for not being dyntick idle, allowing fast entry into
    full-system dyntick-idle state even when there are some offline CPUs.
    
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 79b53bd..687c4e9 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1016,7 +1016,7 @@ int rcu_needs_cpu(int cpu)
 
 	/* Don't bother unless we are the last non-dyntick-idle CPU. */
 	for_each_cpu_not(thatcpu, nohz_cpu_mask)
-		if (thatcpu != cpu) {
+		if (cpu_online(thatcpu) && thatcpu != cpu) {
 			per_cpu(rcu_dyntick_drain, cpu) = 0;
 			per_cpu(rcu_dyntick_holdoff, cpu) = jiffies - 1;
 			return rcu_needs_cpu_quick_check(cpu);

  reply	other threads:[~2010-04-04 23:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-03 22:33 A few questions and issues with dynticks, NOHZ and powertop Dominik Brodowski
2010-04-03 23:53 ` Dmitry Torokhov
2010-04-04 10:35   ` Dominik Brodowski
2010-04-05 20:54     ` Dmitry Torokhov
2010-04-04 10:47   ` Dominik Brodowski
2010-04-05  3:42     ` Arjan van de Ven
2010-04-05 20:41       ` Dominik Brodowski
2010-04-05 20:52         ` Dmitry Torokhov
2010-04-04 15:17 ` Alan Stern
2010-04-04 16:39   ` Dominik Brodowski
2010-04-04 20:47     ` Paul E. McKenney
2010-04-04 23:37       ` Paul E. McKenney [this message]
2010-04-05  3:44         ` Arjan van de Ven
2010-04-05  4:22           ` Paul E. McKenney
2010-04-05 14:40             ` Arjan van de Ven
2010-04-05 15:14               ` Paul E. McKenney
2010-04-05 16:07                 ` Arjan van de Ven
2010-04-05 16:22                   ` Paul E. McKenney
2010-04-05 16:23                     ` Arjan van de Ven
2010-04-05 16:40                       ` Paul E. McKenney
2010-04-05 18:44                   ` david
2010-04-05 19:48                     ` Arjan van de Ven
2010-04-05 20:34                       ` Paul E. McKenney
2010-04-05 21:03       ` Dominik Brodowski
2010-04-05 21:38         ` Paul E. McKenney
2010-04-05 22:11           ` Dominik Brodowski
2010-04-05 22:31             ` Paul E. McKenney
2010-04-06 20:45               ` Dominik Brodowski
2010-04-06 20:59                 ` Paul E. McKenney
2010-04-08 19:59 ` [RFC PATCH] nohz/sched: disable ilb on !mc_capable() Dominik Brodowski

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=20100404233702.GA24102@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=arjan@linux.intel.com \
    --cc=dtor@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --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.