From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752097AbbJBHq7 (ORCPT ); Fri, 2 Oct 2015 03:46:59 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:53400 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751170AbbJBHq5 (ORCPT ); Fri, 2 Oct 2015 03:46:57 -0400 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 165.244.98.76 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com From: To: mingo@kernel.org, peterz@infradead.org CC: linux-kernel@vger.kernel.org, fweisbec@gmail.com, tglx@linutronix.de, Byungchul Park Subject: [PATCH v3 2/2] sched: consider missed ticks when updating global cpu load Date: Fri, 2 Oct 2015 16:46:14 +0900 Message-ID: <1443771974-27077-3-git-send-email-byungchul.park@lge.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1443771974-27077-1-git-send-email-byungchul.park@lge.com> References: <1443771974-27077-1-git-send-email-byungchul.park@lge.com> X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP3HF583 | August 9, 2013) at 2015/10/02 16:46:50, Serialize by Router on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP3HF583 | August 9, 2013) at 2015/10/02 16:46:50, Serialize complete at 2015/10/02 16:46:50 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Byungchul Park 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 --- 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