Messages in this thread | | | Subject | Re: [BUG] "perf top" results in "NOHZ: local_softirq_pending 100" | From | Peter Zijlstra <> | Date | Tue, 07 Dec 2010 14:51:07 +0100 |
| |
On Tue, 2010-12-07 at 14:29 +0100, Heiko Carstens wrote: > > As far as I could see this function gets called from process context with > > a spinlock held and hence we don't have any guarantee that this pending > > softirq get executed before the idle task gets scheduled and tries to > > disable the tick. > > > > The easiest fix would be to set wakeup to one (see patch below), but I guess > > there is a reason why its zero. Anybody?
We can start that hrtimer from within the scheduler function while holding the rq->lock, doing a wakeup from there is not sane.
The best solution would be to fix the hrtimer_start*() interface, something Thomas and I have wanted to do for ages but because we've procrastinated is now a much larger job than it was :/
The whole HRTIMER_SOFTIRQ thing should die.. but for that to happen its only use-case today must first go.
The problem is trying to start a timer with already elapsed time. Preferably hrtimer_start*() would simply return -ETIME and let the caller sort it, sadly the current behaviour is to 'fix' it for the caller by enqueueing the timer onto the softirq list and raising the softirq.
I guess we could make hrtimer_start*(.wakeup=false) return the -ENOTIME thing and audit those few use-cases.
| |