From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4: kvm 1/4] Code motion. Separate timer intialization into an indepedent function. Date: Wed, 30 Sep 2009 17:56:02 +0200 Message-ID: <4AC37F92.2090502@redhat.com> References: <4AC1C59F.6010703@redhat.com> <1254260317-3490-1-git-send-email-zamsden@redhat.com> <4AC31AA5.4060609@redhat.com> <4AC37E81.8080104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti To: Zachary Amsden Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25135 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754739AbZI3P4A (ORCPT ); Wed, 30 Sep 2009 11:56:00 -0400 In-Reply-To: <4AC37E81.8080104@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/30/2009 05:51 PM, Zachary Amsden wrote: >> Is anything preventing us from unifying the constant_tsc and !same >> paths? We could just do a quick check in the notifier, see the tsc >> frequency hasn't changed, and return. > > > Actually, yes. On constant_tsc processors, the processor frequency > may still change, however the TSC frequency does not change with it. > > I actually have both of these kinds of processors (freq changes with > constant TSC and freq changes with variable TSC) so I was able to test > both of these cases. If the API allows us to query the tsc frequency, it would simply return the same values in all cases, which we'd ignore. -- error compiling committee.c: too many arguments to function