On Tue, Jan 28, 2014 at 5:23 AM, Frederic Weisbecker fweisbec@gmail.com wrote:
On Fri, Jan 24, 2014 at 10:51:14AM +0530, Viresh Kumar wrote:
On 23 January 2014 20:28, Frederic Weisbecker fweisbec@gmail.com wrote:
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
So, the main problem in my case was caused by this:
<...>-2147 [001] d..2 302.573881: hrtimer_start:hrtimer=c172aa50 function=tick_sched_timer expires=602075000000 softexpires=602075000000
I have mentioned this earlier when I sent you attachments. I think this is somehow tied with the NO_HZ_FULL stuff? As the timer is queued for 300 seconds after current time.
How to get this out?
So it's scheduled away 300 seconds later. It might be a pending timer_list. Enabling the timer tracepoints may give you some clues.
Trace was done with that enabled. /proc/timer_list confirms that a hrtimer is queued for 300 seconds later for tick_sched_timer. And so I assumed this is part of the current NO_HZ_FULL implementation.
Just to confirm, when we decide that a CPU is running a single task and so can enter tickless mode, do we queue this tick_sched_timer for 300 seconds ahead of time? If not, then who is doing this :)
No, when a single task is running on a full dynticks CPU, the tick is supposed to run every seconds. I'm actually suprised it doesn't happen in your traces, did you tweak something specific?
I think Viresh is using my patch/hack to configure/disable the 1Hz residual tick.
Kevin