From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752488AbcHMInH (ORCPT ); Sat, 13 Aug 2016 04:43:07 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36037 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752395AbcHMImw (ORCPT ); Sat, 13 Aug 2016 04:42:52 -0400 Date: Sat, 13 Aug 2016 10:42:47 +0200 From: Ingo Molnar To: Rik van Riel Cc: Wanpeng Li , Frederic Weisbecker , LKML , Paolo Bonzini , Peter Zijlstra , Wanpeng Li , Thomas Gleixner , Radim Krcmar , Mike Galbraith Subject: Re: [PATCH] time,virt: resync steal time when guest & host lose sync Message-ID: <20160813084247.GA20927@gmail.com> References: <1468421405-20056-1-git-send-email-fweisbec@gmail.com> <1468421405-20056-2-git-send-email-fweisbec@gmail.com> <1470751579.13905.77.camel@redhat.com> <20160810125212.78564dc2@annuminas.surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160810125212.78564dc2@annuminas.surriel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Rik van Riel wrote: > On Wed, 10 Aug 2016 07:39:08 +0800 > Wanpeng Li wrote: > > > The regression is caused by your commit "sched,time: Count actually > > elapsed irq & softirq time". > > Wanpeng, does this patch fix your issue? > > Paolo, what is your opinion on this issue? > > I can think of all kinds of ways in which guest and host might lose > sync with steal time, from uninitialized values at boot, to guest > pause, followed by save to disk, and reload, to live migration, to... > > ---8<--- > > Subject: time,virt: resync steal time when guest & host lose sync > > When guest and host wildly disagree on steal time, a guest can > do several things: > 1) Quickly account all the steal time at once (the kernel did this before > 57430218317e ("sched/cputime: Count actually elapsed irq & softirq time"), > when steal_account_process_ticks got ULONG_MAX as its maximum value. > 2) Stay out of sync for an indeterminate amount of time. This is what the > system does today. > 3) Sync up the guest value to the host-provided value, without accounting > an absurdly large value in the cpu time statistics. > > This patch makes the kernel do (3), which seems like the right thing > to do. > > The exact value of the threshold use probably does not matter too much, > as long as it is long enough to cover all the timer ticks that passed > during an idle period, because (irqtime_)account_idle_ticks can process > a large amount of time all at once. > > Signed-off-by: Rik van Riel > Reported-by: Wanpeng Li > --- > kernel/sched/cputime.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) fails to build on x86 allnoconfig: kernel/sched/cputime.c:524:10: error: too many arguments to function ‘steal_account_process_time’ Thanks, Ingo