From: Byungchul Park <[email protected]> in hrtimer_interrupt(), the first tick_program_event() can be failed because the next timer could be already expired due to, (see the comment in hrtimer_interrupt())
- tracing - long lasting callbacks - being scheduled away when running in a VM in the case that the first tick_program_event() is failed, the second tick_program_event() set the expired time to more than one tick later. then next tick can happen after more than one tick, even though tick is not stopped by e.g. NOHZ. when the next tick occurs, update_process_times() -> scheduler_tick() -> update_cpu_load_active() is performed, assuming the distance between last tick and current tick is 1 tick! it's wrong in this case. thus, this abnormal case should be considered in update_cpu_load_active(). Signed-off-by: Byungchul Park <[email protected]> --- kernel/sched/fair.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9e76871..14b9757 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4388,12 +4388,15 @@ void update_cpu_load_nohz(void) */ void update_cpu_load_active(struct rq *this_rq) { + unsigned long curr_jiffies = READ_ONCE(jiffies); + unsigned long pending_updates; unsigned long load = weighted_cpuload(cpu_of(this_rq)); /* * See the mess around update_idle_cpu_load() / update_cpu_load_nohz(). */ - this_rq->last_load_update_tick = jiffies; - __update_cpu_load(this_rq, load, 1, 1); + pending_updates = curr_jiffies - this_rq->last_load_update_tick; + this_rq->last_load_update_tick = curr_jiffies; + __update_cpu_load(this_rq, load, pending_updates, 1); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
