On 10/02/2013 05:57 PM, Frederic Weisbecker wrote:
2013/10/2 Daniel Lezcano daniel.lezcano@linaro.org:
The sleep_length is computed in the tick_nohz_stop_sched_tick function but it is used later in the code with in between the local irq enabled.
cpu_idle_loop tick_nohz_idle_enter [ exits with local irq enabled ] __tick_nohz_idle_enter tick_nohz_stop_sched_tick ...
arch_cpu_idle menu_select [ uses here 'sleep_length' ] ...
Between the computation of the sleep length and its usage, some interrupts may occur, making the sleep length shorter than actually it is because of the interrupt processing
So, do you mean that the ts->sleep_length would return a value that is too long given that the CPU already spent some time to service the irqs since we computed the sleep length in tick_nohz_idle_enter()?
But then tick_nohz_irq_exit() should take care of that as it calls again tick_nohz_stop_sched_tick(). So I'm a bit confused.
or different if the timer itself expired.
Same here, if the timer expired, it triggers an interrupt which can do two things:
- reprogram a new timer and this recompute sleep_length
- set_need_resched() and then exit the idle loop, so arch_cpu_idle() won't even
be called. Or the timer interrupts hlt, but then menu_select() was called before.
So I probably missed something here.
No you did not :)
Indeed... At the first glance, this issue sounded so obvious I suspected there must be a trick somewhere but I did not think to look at the irq_exit, the code is very complex. Thanks for clarifying this.
For my personal information, is there any particular reason to set an intermediate 'sleep_length' in tick_nohz_stop_sched_tick instead of doing what does this patch ?
Thanks -- Daniel