Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-03 Thread Mike Galbraith
On Mon, 2014-02-03 at 09:31 +0100, Sebastian Andrzej Siewior wrote: > On 02/03/2014 05:00 AM, Mike Galbraith wrote: > > On Sun, 2014-02-02 at 21:10 +0100, Sebastian Andrzej Siewior wrote: > > > >> According to the backtrace both of them are trying to access the > >> per-cpu hrtimer (sched_timer)

Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-03 Thread Sebastian Andrzej Siewior
On 02/03/2014 05:00 AM, Mike Galbraith wrote: > On Sun, 2014-02-02 at 21:10 +0100, Sebastian Andrzej Siewior wrote: > >> According to the backtrace both of them are trying to access the >> per-cpu hrtimer (sched_timer) in order to cancel but they seem to fail >> to get the timer lock here. They sh

Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-02 Thread Mike Galbraith
On Sun, 2014-02-02 at 21:10 +0100, Sebastian Andrzej Siewior wrote: > According to the backtrace both of them are trying to access the > per-cpu hrtimer (sched_timer) in order to cancel but they seem to fail > to get the timer lock here. They shouldn't spin there for minutes, I > have no idea why

Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-02 Thread Mike Galbraith
On Sun, 2014-02-02 at 21:10 +0100, Sebastian Andrzej Siewior wrote: > So CPU5 & CPU52 were eating 100% CPU doing "nothing" instead of running > cc1 & objdump right? Yeah. > According to the backtrace both of them are trying to access the > per-cpu hrtimer (sched_timer) in order to cancel but the

Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-02 Thread Sebastian Andrzej Siewior
On 02/02/2014 05:22 AM, Mike Galbraith wrote: > This patch (w. too noisy to live pr_err whacked) reliable kills my 64 > core test box, but only in _virgin_ 3.12-rt11. Add my local patches, > and it runs and runs, happy as a clam. Odd. But whatever, box with > virgin source running says it's bust

Re: [PATCH 1/2] irq_work: allow certain work in hard irq context

2014-02-01 Thread Mike Galbraith
On Fri, 2014-01-31 at 15:34 +0100, Sebastian Andrzej Siewior wrote: > irq_work is processed in softirq context on -RT because we want to avoid > long latencies which might arise from processing lots of perf events. > The noHZ-full mode requires its callback to be called from real hardirq > context

[PATCH 1/2] irq_work: allow certain work in hard irq context

2014-01-31 Thread Sebastian Andrzej Siewior
irq_work is processed in softirq context on -RT because we want to avoid long latencies which might arise from processing lots of perf events. The noHZ-full mode requires its callback to be called from real hardirq context (commit 76c24fb ("nohz: New APIs to re-evaluate the tick on full dynticks CP