lkml.org 
[lkml]   [2011]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL rcu/next] rcu commits for 2.6.40

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> On Fri, May 13, 2011 at 03:12:18PM +0200, Ingo Molnar wrote:
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > I started bisecting this, and the two relevant endpoints:
> > >
> > > bad: 11c476f: net,rcu: convert call_rcu(prl_entry_destroy_rcu) to kfree
> > > good: 0ee5623f: Linux 2.6.39-rc6
> > >
> > > very clearly indicate that this is an RCU regression.
> >
> > This might be the same one Yinghai found:
> >
> > e59fb3120bec: rcu: Decrease memory-barrier usage based on semi-formal proof
> >
> > So with the config i sent it's definitely reproducible.
> >
> > At first sight couldnt this be related not to barriers, but to not setting
> > need_resched() like we did before?
>
> Thank you both!!! I had inspected the commit, but missed the fact that
> the new version refuses to call set_need_resched() if irqs are enabled. :-(
> The following (untested) patch restores the set_need_resched() operation.

Btw., in hindsight, e59fb3120bec was a tad big, which made analysis harder.

Would it have been possible to split it in two, one for the movement of the
notifiers, the other for the barrier changes?

That way the bisection would have fingered the movement commit. Or so.

> Does this help?

No, unfortunately not, the long delay is still there:

device: 'ttyS0': device_add
PM: Adding info for No Bus:ttyS0
INFO: rcu_sched_state detected stalls on CPUs/tasks: { 0} (detected by 1, t=6002 jiffies)

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-05-13 17:09    [W:0.092 / U:2.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site