From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754287AbcFGIeD (ORCPT ); Tue, 7 Jun 2016 04:34:03 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:33329 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754256AbcFGId4 (ORCPT ); Tue, 7 Jun 2016 04:33:56 -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 v4 2/3] sched/cputime: Fix prev steal time accouting during cpu hotplug Date: Tue, 7 Jun 2016 16:33:08 +0800 Message-Id: <1465288389-3542-2-git-send-email-wanpeng.li@hotmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1465288389-3542-1-git-send-email-wanpeng.li@hotmail.com> References: <1465288389-3542-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 setting rq->prev_* to current irq time and steal clock timestamp after a cpu hotplug comes back. 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 --- kernel/sched/sched.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 72f1f30..e6758af 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1813,12 +1813,12 @@ static inline void cpufreq_trigger_update(u64 time) {} static inline void account_reset_rq(struct rq *rq) { #ifdef CONFIG_IRQ_TIME_ACCOUNTING - rq->prev_irq_time = 0; + rq->prev_irq_time = irq_time_read(cpu_of(rq)); #endif #ifdef CONFIG_PARAVIRT - rq->prev_steal_time = 0; + rq->prev_steal_time = paravirt_steal_clock(cpu_of(rq)); #endif #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING - rq->prev_steal_time_rq = 0; + rq->prev_steal_time_rq = paravirt_steal_clock(cpu_of(rq)); #endif } -- 1.9.1