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 18:11:44 +0200 Message-ID: <4AC38340.4000305@redhat.com> References: <4AC1C59F.6010703@redhat.com> <1254260317-3490-1-git-send-email-zamsden@redhat.com> <4AC31AA5.4060609@redhat.com> <4AC37E81.8080104@redhat.com> <4AC37F92.2090502@redhat.com> <4AC3821D.2050900@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]:29728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751804AbZI3QLm (ORCPT ); Wed, 30 Sep 2009 12:11:42 -0400 In-Reply-To: <4AC3821D.2050900@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/30/2009 06:06 PM, Zachary Amsden wrote: > On 09/30/2009 05:56 AM, Avi Kivity wrote: >> On 09/30/2009 05:51 PM, Zachary Amsden wrote: >> >> If the API allows us to query the tsc frequency, it would simply >> return the same values in all cases, which we'd ignore. > > The API only allows querying the processor frequency. In the > constant_tsc case, the highest processor frequency is likely going to > be the actual TSC frequency, but I don't think it's a guarantee; > theoretically, it could be faster on normal hardware ... or slower on > overclocked hardware with an externally clocked TSC. Well we could add a new API then (or a new tscfreq notifier). Those conditionals don't belong in client code. -- error compiling committee.c: too many arguments to function