Re: linux-next: Tree for April 14 (Call-traces: RCU/ACPI/WQ related?)

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Apr 22, 2011 at 11:40:54AM +0200, Sedat Dilek wrote:
> On Fri, Apr 22, 2011 at 2:50 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Thu, Apr 21, 2011 at 04:47:31PM +0200, Sedat Dilek wrote:
> >> On Thu, Apr 21, 2011 at 4:28 PM, Paul E. McKenney
> >> <paulmck@linux.vnet.ibm.com> wrote:
> >> > On Thu, Apr 21, 2011 at 02:49:37PM +0200, Sedat Dilek wrote:
> >> >> On Thu, Apr 21, 2011 at 12:24 PM, Sedat Dilek
> >> >> <sedat.dilek@googlemail.com> wrote:
> >
> > [ . . . ]
> >
> >> >> Here the results from the 2nd-run (PREEMPT_RCU enabled).
> >> >
> >> > OK, and the grace periods clearly stopped advancing early on.
> >> >
> >> > Beyond that point, the per-CPU kthread is blocked, but RCU has some
> >> > work for it to do.  So someone has called invoke_rcu_cpu_kthread(),
> >> > but rcu_cpu_kthread() is still blocked.  I don't see a bug right
> >> > off-hand, but it is early in the morning for me, so I might easily
> >> > be missing something.
> >> >
> >> > Hmmm...
> >> >
> >> > The synchronization between these two assumes that the per-CPU
> >> > kthread is always bound to the respective CPU, so if was somehow
> >> > being migrated off, that might explain these results.
> >> >
> >> > I will add some more diagnostics, test them locally, then push
> >> > out an update.  Seem reasonable?
> >> >
> >> > And thank you again for the testing!!!
> >>
> >> Ping me when you have new stuff for testing.
> >> Tomorrow (friday), here is public holiday and monday, too.
> >> So a looong weekend.
> >
> > ;-)
> >
> > OK, I have a new sedat.2011.04.21a branch in the -rcu git tree:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> >
> > This is against 2.6.39-rc3, as before.  (Yes, I do need to rebase to
> > 2.6.39-rc4, but didn't want to change any more than I had to.)
> >
> > I also have an updated script, which is attached.  The output is similar
> > to the earlier one, and it operated is pretty much the same way.
> >
> > Have a great weekend, and I look forward to seeing what shows up on
> > this round.  I confess to still being quite puzzled!
> >
> >                                                        Thanx, Paul
> >
> 
> Here are the results of the Sedat's vote (European song contest :-)).

;-)

Very strange.  RCU has told the per-CPU kthread that it needs to get
to work, but this kthread is still waiting from RCU's viewpoint.
Yet the "ps" command believes that this kthread is in fact runnable
at SCHED_FIFO priority 1.

I can tell that this one will require some thought...  And more
diagnostics...

							Thanx, Paul