From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932202AbcFHDF6 (ORCPT ); Tue, 7 Jun 2016 23:05:58 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:36800 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755776AbcFHDFz (ORCPT ); Tue, 7 Jun 2016 23:05:55 -0400 From: Wanpeng Li X-Google-Original-From: Wanpeng Li To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Wanpeng Li , Ingo Molnar , "Peter Zijlstra (Intel)" , Rik van Riel , Thomas Gleixner , Frederic Weisbecker , Paolo Bonzini , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= Subject: [PATCH v5 2/3] sched/cputime: Fix prev steal time accouting during cpu hotplug Date: Wed, 8 Jun 2016 11:05:09 +0800 Message-Id: <1465355110-21714-2-git-send-email-wanpeng.li@hotmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1465355110-21714-1-git-send-email-wanpeng.li@hotmail.com> References: <1465355110-21714-1-git-send-email-wanpeng.li@hotmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Wanpeng Li Commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") set rq->prev_* to 0 after a cpu hotplug comes back in order to fix the scenario: | steal is smaller than rq->prev_steal_time we end up with an insane large | value which then gets added to rq->prev_steal_time, resulting in a permanent | wreckage of the accounting. However, it is still buggy. rq->prev_steal_time = 0: As Rik pointed out: | setting rq->prev_irq_time to 0 in the guest, and then getting a giant value from | the host, could result in a very large of steal_jiffies. rq->prev_steal_time_rq = 0: | steal = paravirt_steal_clock(cpu_of(rq)); | steal -= rq->prev_steal_time_rq; | | if (unlikely(steal > delta)) | steal = delta; | | rq->prev_steal_time_rq += steal; | delta -= steal; | | rq->clock_task += delta; steal is a giant value and rq->prev_steal_time_rq is 0, rq->prev_steal_time_rq grows in delta granularity, rq->clock_task can't ramp up until rq->prev_steal_time_rq catches up steal clock since delta value will be 0 after reducing steal time from normal execution time. That's why I obersved that cpuhg/1-12 continue running until rq->prev_steal_time_rq catches up steal clock timestamp. I believe rq->prev_irq_time has similar issue. So this patch fix it by reverting commit e9532e69b8d1. Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")' Acked-by: Rik van Riel Cc: Ingo Molnar Cc: Peter Zijlstra (Intel) Cc: Rik van Riel Cc: Thomas Gleixner Cc: Frederic Weisbecker Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- v4 -> v5: * revert commit e9532e69b8d1 kernel/sched/core.c | 1 - kernel/sched/sched.h | 13 ------------- 2 files changed, 14 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7f2cae4..7d45bb3 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7213,7 +7213,6 @@ static void sched_rq_cpu_starting(unsigned int cpu) struct rq *rq = cpu_rq(cpu); rq->calc_load_update = calc_load_update; - account_reset_rq(rq); update_max_interval(); } diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 72f1f30..de607e4 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1809,16 +1809,3 @@ static inline void cpufreq_trigger_update(u64 time) {} #else /* arch_scale_freq_capacity */ #define arch_scale_freq_invariant() (false) #endif - -static inline void account_reset_rq(struct rq *rq) -{ -#ifdef CONFIG_IRQ_TIME_ACCOUNTING - rq->prev_irq_time = 0; -#endif -#ifdef CONFIG_PARAVIRT - rq->prev_steal_time = 0; -#endif -#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING - rq->prev_steal_time_rq = 0; -#endif -} -- 1.9.1