On Fri, Aug 12, 2016 at 11:58:03AM -0400, Rik van Riel wrote: > On Fri, 12 Aug 2016 15:09:00 +0800 > Wanpeng Li <kernel...@gmail.com> wrote: > > 2016-08-12 10:44 GMT+08:00 Rik van Riel <r...@redhat.com>: > > > > If you pass ULONG_MAX as the maxtime argument to > > > steal_account_process_time(), does the steal time > > > get accounted properly at 75%? > > > > Yes. > > I talked with Paolo this morning, and it turns out that if a guest > misses several timer ticks in a row, they will simply get lost. > > That means the functions calling steal_account_process_time may not > know how much CPU time has passed since the last time it was called, > but steal_account_process_time will get a good idea on how much time > the host spent running something else. > > Removing the limit, and documenting why, seems like the right way to > fix this bug. > > Wanpeng, does the patch below work for you? > > Everybody else, does this patch look acceptable? > > ---8<--- > Subject: time,virt: do not limit steal_account_process_time > > 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. > > Instead, simply let steal_account_process_time account however much > steal time the host told us elapsed. This can make up timer ticks > that were missed when the host scheduled somebody else. > > Signed-off-by: Rik van Riel <r...@redhat.com> > Reported-by: Wanpeng Li <kernel...@gmail.com>
I much prefer this version. After all, even if that time spent in host is very large, it's still stolen time and we want to account it. Thanks.
