From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: RFC: kvmclock / tsc server side fix Date: Tue, 18 May 2010 05:00:34 -1000 Message-ID: <4BF2AB92.70907@redhat.com> References: <4BEE01EF.7000506@redhat.com> <20100517153637.GD2893@mothafucka.localdomain> <4BF19B36.7030100@redhat.com> <20100518140829.GA30739@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm , Avi Kivity , Marcelo Tosatti To: Glauber Costa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25047 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757243Ab0ERPAj (ORCPT ); Tue, 18 May 2010 11:00:39 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4IF0dId025296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 May 2010 11:00:39 -0400 In-Reply-To: <20100518140829.GA30739@mothafucka.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 05/18/2010 04:08 AM, Glauber Costa wrote: > On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote: > >> On 05/17/2010 05:36 AM, Glauber Costa wrote: >> >>> On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote: >>> >>>> I believe this fixes the root cause of the kvmclock warp. It's >>>> quite a plausible phenomenon, and explains why it was so easy to >>>> produce. >>>> >>>> >>> You mean this is the case for both SMP and UP, or just UP as we talked >>> before? >>> >> It's possible on both SMP and UP, guest and host. It is impossible >> on UP host unless special circumstances come into play (one of my >> patches created these circumstances). >> >> >>> I don't get the role of upscale in your patch. Frequency changes are >>> already handled by the cpufreq notifier. >>> >> The only purpose of upscale is to downscale the measurement of delta >> used for counting stats if CPU frequency was raised since last >> observed. This is because moving to a faster TSC rate means we >> might have counted some cycles at the wrong rate while the rate was >> in transition. It doesn't much matter, as the delta for which >> "overrun" is logged was computed wrong anyway. >> > mind sending the stats part in a separate patch? > Yeah, part of this was badly broken. > >> I'll clean up my patches and resend as a series today. >> >> Zach >> Or today. Nasty bug.