Messages in this thread | | | Date | Fri, 13 May 2011 17:07:44 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |