From: Wanpeng Li <wanpeng...@hotmail.com>
I observed that sometimes st is 100% instantaneous, then idle is 100%
even if there is a cpu hog on the guest cpu after the cpu hotplug comes
back(N.B. both guest and host are latest 4.7-rc1, this can not always
be readily reproduced). I add trace to capture it as below:
cpuhp/1-12 [001] d.h1 167.461657: account_process_tick: steal =
1291385514, prev_steal_time = 0
cpuhp/1-12 [001] d.h1 167.461659: account_process_tick: steal_jiffies =
1291
<idle>-0 [001] d.h1 167.462663: account_process_tick: steal = 18732255,
prev_steal_time = 1291000000
<idle>-0 [001] d.h1 167.462664: account_process_tick: steal_jiffies =
18446744072437
The steal clock warps and then steal_jiffies overflow, this patch align
prev_steal_time to the new steal clock timestamp, in order to avoid
overflow and st stuff can continue to work.
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Peter Zijlstra (Intel) <pet...@infradead.org>
Cc: Rik van Riel <r...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Frederic Weisbecker <fweis...@gmail.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim <rkrc...@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com>
---
kernel/sched/cputime.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 75f98c5..d0eebc3 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -265,7 +265,13 @@ static __always_inline bool
steal_account_process_tick(void)
unsigned long steal_jiffies;
steal = paravirt_steal_clock(smp_processor_id());
- steal -= this_rq()->prev_steal_time;
+ if (likely(steal > this_rq()->prev_steal_time))
+ steal -= this_rq()->prev_steal_time;
+ else {
+ /* steal clock warp */
+ this_rq()->prev_steal_time = steal;
+ return false;
+ }
/*
* steal is in nsecs but our caller is expecting steal
--
1.9.1
