Re: [tip:sched/core] sched/cputime: Resync steal time when guest & host lose sync

[Frederic Weisbecker]

On Thu, Aug 18, 2016 at 03:55:39AM -0700, tip-bot for Wanpeng Li wrote:
> Commit-ID:  03cbc732639ddcad15218c4b2046d255851ff1e3
> Gitweb:     http://git.kernel.org/tip/03cbc732639ddcad15218c4b2046d255851ff1e3
> Author:     Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
> AuthorDate: Wed, 17 Aug 2016 10:05:46 +0800
> Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
> CommitDate: Thu, 18 Aug 2016 11:19:48 +0200
> 
> sched/cputime: Resync steal time when guest & host lose sync
> 
> Commit:
> 
>   57430218317e ("sched/cputime: Count actually elapsed irq & softirq time")
> 
> ... fixed a bug but also triggered a regression:
> 
> On an i5 laptop, 4 pCPUs, 4vCPUs for one full dynticks guest, there are four
> CPU hog processes(for loop) running in the guest, I hot-unplug the pCPUs
> on host one by one until there is only one left, then observe CPU utilization
> via 'top' in the guest, it shows:
> 
>   100% st for cpu0(housekeeping)
>    75% st for other CPUs (nohz full mode)
> 
> However, w/o this commit it shows the correct 75% for all four CPUs.
> 
> When a guest is interrupted for a longer amount of time, missed clock ticks
> are not redelivered later. Because of that, we should not limit the amount
> of steal time accounted to the amount of time that the calling functions
> think have passed.
> 
> However, the interval returned by account_other_time() is NOT rounded down
> to the nearest jiffy, while the base interval in get_vtime_delta() it is
> subtracted from is, so the max cputime limit is required to avoid underflow.
> 
> This patch fixes the regression by limiting the account_other_time() from
> get_vtime_delta() to avoid underflow, and lets the other three call sites
> (in account_other_time() and steal_account_process_time()) account however
> much steal time the host told us elapsed.
> 
> Suggested-by: Rik van Riel <riel@xxxxxxxxxx>
> Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
> Reviewed-by: Rik van Riel <riel@xxxxxxxxxx>
> Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>

ACK, thanks Wanpeng Li!