From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752901AbcHMHT2 convert rfc822-to-8bit (ORCPT ); Sat, 13 Aug 2016 03:19:28 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:45288 "EHLO mx5-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbcHMHT1 (ORCPT ); Sat, 13 Aug 2016 03:19:27 -0400 Date: Sat, 13 Aug 2016 03:18:42 -0400 (EDT) From: Paolo Bonzini To: Rik van Riel Cc: Wanpeng Li , Frederic Weisbecker , Ingo Molnar , LKML , Peter Zijlstra , Wanpeng Li , Thomas Gleixner , Radim Krcmar , Mike Galbraith Message-ID: <974330607.1641549.1471072722360.JavaMail.zimbra@redhat.com> In-Reply-To: <1471022601.32433.2.camel@redhat.com> References: <1468421405-20056-1-git-send-email-fweisbec@gmail.com> <1470751579.13905.77.camel@redhat.com> <20160810125212.78564dc2@annuminas.surriel.com> <1471022601.32433.2.camel@redhat.com> Subject: Re: [PATCH] time,virt: resync steal time when guest & host lose sync MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.4.164.1, 10.5.100.50] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922) Thread-Topic: time,virt: resync steal time when guest & host lose sync Thread-Index: 7d6AaNOhJbYK0grxlA1cisXocKyN/Q== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > There is one copy of paravirt_steal_clock(smp_processor_id()), > but what keeps it in sync with this_rq()->prev_steal_time? > > Is it something simple like them both being zeroed out when > the structures are first allocated at boot time? Yes, more precisely both of them being equal when the MSR is written to. They are just memory locations so they remain in sync across pause, migration and the like, and prev_steal_time is only ever updated with a previous value of paravirt_steal_clock(). > > Your hypothesis of lost ticks makes the most sense to me, and then > > changing the argument to ULONG_MAX is the right thing to do. > > I sent out a patch that just removes the parameter instead, > and documents why steal_account_process_time can encounter > more elapsed time than the calling functions expected. Good, thanks! Paolo