On Tue, 29 Mar 2016 18:25:56 +0200 Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > * Luiz Capitulino | 2016-03-21 15:12:38 [-0400]: > > >nohz support (nohz-full and nohz-idle) is currently > >broken in the RT kernel. Meaning that, the tick is > >never de-activated even when a core is idle or when > >nohz_full= is passed. > > > >The reason for this is that get_next_timer_interrupt() > >in the RT kernel *always* returns "basem + TICK_NSEC" > >which translates to "there's a timer firing in the > >next tick". This causes tick_nohz_stop_sched_tick() > >to never deactivate the tick. > > > >This patch is like tylenol, it doesn't fix the problem, it > >just reliefs the symptons by making tick_nohz_stop_sched_tick() > >succeed if: 1. a core doesn't have any legacy timers > >pending and 2. there's no hrtimer firing in the next tick. > > > >Also, note that this issue has another side effect: it > >causes the ktimersoftd thread to always take 1%-2% of CPU > >time on all cores, even if they are idle. As it turns out, > >the tick handling code path unconditionally raises the > >TIMER_SOFTIRQ line. This is an upstream kernel behavior. > >I believe people are not noticing the CPU usage because > >nohz-idle papers over this problem. > > Unless this gets an ack-by tglx I will not consider it. Thomas? > Last time it was > decided that we first rework the timer wheel before getting full-nohz > fixed for -RT. Is there anyone working on it? What needs to be done? > This patch disables interrupts to read an integer which should be safe > without interrupts disabled. I think you're right, it shouldn't be necessary to disable interrupts. > What are the implications if the value > changes after read (say after the interrupt enable)? > > >Signed-off-by: Luiz Capitulino <lcapitulino@xxxxxxxxxx> > > Sebastian > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
