All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Ingo Molnar <mingo@elte.hu>,
	Ben Herrenschmidt <benh@kernel.crashing.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: CONFIG_PREEMPT_RCU in next/mmotm
Date: Sat, 8 Aug 2009 16:56:34 -0700	[thread overview]
Message-ID: <20090808235634.GB6866@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0908081956580.12300@sister.anvils>

On Sat, Aug 08, 2009 at 08:34:03PM +0100, Hugh Dickins wrote:
> Hi Paul,
> 
> Is CONFIG_PREEMPT_RCU=y expected to be working in -next (or mmotm)?
> 
> I ask because it appears to break down on PowerPC G5 when I try two
> "make -j20" kernel builds in parallel.  The "filp" slab which usually
> contains a couple of thousand objects or so, jumps up to a couple of
> hundred thousand before the builds complete, and continues rising
> from then on - I think that's a sign of RCU in disgrace?
> And rebooting hangs thereafter.

That would indeed be bad.

> And I notice that include/linux/rcupreempt.h currently says:
> static inline void synchronize_rcu_expedited(void)
> {
> 	synchronize_rcu();  /* Placeholder for new rcupreempt implementation. */
> }
> which gives an impression of work in progress?

Yep, but I would be surprised if this was causing your problem.  In fact,
I would be surprised if this function was being invoked.  Then again,
I have been surprised more than once.

For whatever it is worth, with luck, include/linux/rcupreempt.h disappears
entirely at some point.

> CONFIG_PREEMPT_TREE=y seems okay on PowerPC; and when I briefly tried

CONFIG_TREE_RCU=y, you mean, right?

> CONFIG_PREEMPT_RCU=y on x86_64, it didn't show above symptoms there.

Interesting...

> I did try bisecting yesterday's linux-next git, but that led me to
> 
> commit 8ca17c6082feee5841a7b0e91d00e18c3f85f063
> Merge: dafcc6e... 7256cf0...
> Author: Ingo Molnar <mingo@elte.hu>
> Date:   Mon Aug 3 15:50:37 2009 +0200
> 
>     Merge branch 'core/rcu' into auto-sched-next
> 
> rather than to any particular patch of yours which that merges:
> which seemed odd, but I'm not accustomed to bisecting next.

I honestly don't know how "git bisect" interacts with merges.

> Another odd thing is that mmotm .DATE=2009-07-30-05-01, the last
> I tried before Thursday's, showed no such symptoms: yet appears to
> contain all the larger RCU changes, just lacking some more recent
> on/offline race fixes.  I didn't notice any likely difference
> between those mmotm trees down in arch/powerpc either.
> 
> My guess is that there's some other issue which is triggering
> the RCU disgrace, but that is just a guess.

The one other issue I know of is one that apparently happens only on
one of Ingo's machines, which suddenly decides that it need not inform
RCU when onlining a CPU (at boot time).

But you seem to be making it past boot, and I would guess that you are
not doing any hotplug CPU operations, right?

> Config attached.  Any suggestions?

/me scratches head...  Will try some more CONFIG_PREEMPT_RCU testing
locally.

							Thanx, Paul

  reply	other threads:[~2009-08-08 23:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 19:34 CONFIG_PREEMPT_RCU in next/mmotm Hugh Dickins
2009-08-08 23:56 ` Paul E. McKenney [this message]
2009-08-09  3:32   ` Hugh Dickins
2009-08-09  5:33     ` Paul E. McKenney
2009-08-09 11:24       ` Hugh Dickins
2009-08-09 13:06         ` Hugh Dickins
2009-08-09 18:57           ` Paul E. McKenney
2009-08-09 20:53             ` Hugh Dickins
2009-08-09 21:16               ` Paul E. McKenney
2009-08-10  3:39                 ` Paul E. McKenney
2009-08-10 22:43                   ` Paul E. McKenney
2009-08-12  1:34                     ` Paul E. McKenney
2009-08-12  9:22                       ` Ingo Molnar
2009-08-13  0:51                         ` 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=20090808235634.GB6866@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.