Thread (21 messages) 21 messages, 3 authors, 2014-01-27

Re: [PATCH] rcu: Eliminate softirq processing from rcutree

From: Mike Galbraith <hidden>
Date: 2014-01-27 17:03:55
Also in: lkml

On Mon, 2014-01-27 at 08:54 -0800, Paul E. McKenney wrote: 
On Mon, Jan 27, 2014 at 06:10:44AM +0100, Mike Galbraith wrote:
quoted
On Sat, 2014-01-25 at 06:12 +0100, Mike Galbraith wrote: 
quoted
On Fri, 2014-01-24 at 20:50 +0100, Sebastian Andrzej Siewior wrote: 
quoted
* Mike Galbraith | 2014-01-18 04:25:14 [+0100]:
quoted
quoted
quoted
# timers-do-not-raise-softirq-unconditionally.patch
# rtmutex-use-a-trylock-for-waiter-lock-in-trylock.patch

..those two out does seem to have stabilized the thing.
timers-do-not-raise-softirq-unconditionally.patch is on its way out.

rtmutex-use-a-trylock-for-waiter-lock-in-trylock.patch confues me.
Didn't you report once that your box deadlocks without this patch? Now
your 64way box on the other hand does not work with it?
If 'do not raise' is applied, 'use a trylock' won't save you.  If 'do
is this just an observation or you do know why it won't save me?
It's an observation from beyond the grave from the 64 core box that it
repeatedly did NOT save :)  Autopsy photos below.

I've built 3.12.8-rt9 with Stevens v2 "timer: Raise softirq if there's
irq_work" to see if it'll survive.
And it did, configured both as nohz_tick, and nohz_full_all.  The irqs
are enabled warning in can_stop_full_tick() fired for nohz_full_all, but
that's it.

For grins, I also applied Paul's v3 timer latency series while testing
nohz_full_all config.   The box was heavily loaded the vast majority of
the time, but it didn't explode or do anything obviously evil.
Cool!  May I add your Tested-by?
Certainly.

-Mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help