From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: David Witbrodt <dawitbro@sbcglobal.net>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Yinghai Lu <yhlu.kernel@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, netdev <netdev@vger.kernel.org>
Subject: [PATCH diagnostic] Prevent console flood when one CPU sees another AWOL via RCU
Date: Tue, 12 Aug 2008 17:25:03 -0700 [thread overview]
Message-ID: <20080813002503.GA25397@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080811131727.GL8125@linux.vnet.ibm.com>
On Mon, Aug 11, 2008 at 06:17:28AM -0700, Paul E. McKenney wrote:
> On Mon, Aug 11, 2008 at 01:38:17PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > And here is the patch. It is still a bit raw, so the results should
> > > be viewed with some suspicion. It adds a default-off kernel parameter
> > > CONFIG_RCU_CPU_STALL which must be enabled.
> > >
> > > Rather than exponential backoff, it backs off to once per 30 seconds.
> > > My feeling upon thinking on it was that if you have stalled RCU grace
> > > periods for that long, a few extra printk() messages are probably the
> > > least of your worries...
> >
> > while this wont debug problems were timer irqs are genuinely stuck for
> > long periods of time, it should find problems with RCU completion logic
> > itself in the presence of correct timer irqs - and the lack of any
> > messages from this debug option should point the finger more firmly in
> > the direction of stalled timer irqs.
> >
> > So i find this debug feature rather useful and have applied it to
> > tip/core/rcu (and cleaned it up a bit). I renamed the config option to
> > CONFIG_DEBUG_RCU_STALL to make it more in line with usual debug option
> > names. Lets see whether -tip testing finds any false positives.
>
> Sounds good!
>
> For whatever it is worth, this diagnostic can also locate latency issues
> in non-CONFIG_PREEMPT kernels, even when those problems are outside of
> preempt_disable() regions. Latency tracer is of course a better tool
> for things -inside- of preempt_disable() regions.
One small change needed to keep from flooding the console when one
CPU notices that another is AWOL. Unless I am missing something subtle.
Otherwise the cleanups look good!
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
rcuclassic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/rcuclassic.c b/kernel/rcuclassic.c
index 56b8712..dab2676 100644
--- a/kernel/rcuclassic.c
+++ b/kernel/rcuclassic.c
@@ -308,6 +308,7 @@ static void print_other_cpu_stall(struct rcu_ctrlblk *rcp)
spin_unlock(&rcp->lock);
return;
}
+ rcp->gp_check = get_seconds() + 30;
spin_unlock(&rcp->lock);
/* OK, time to rat on our buddy... */
prev parent reply other threads:[~2008-08-13 0:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-09 22:35 HPET regression in 2.6.26 versus 2.6.25 -- RCU problem David Witbrodt
2008-08-10 15:15 ` Paul E. McKenney
2008-08-11 1:35 ` [PATCH diagnostic] " Paul E. McKenney
2008-08-11 1:38 ` Paul E. McKenney
2008-08-11 11:38 ` Ingo Molnar
2008-08-11 13:17 ` Paul E. McKenney
2008-08-13 0:25 ` Paul E. McKenney [this message]
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=20080813002503.GA25397@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dawitbro@sbcglobal.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.com \
/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.