From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matt T. Yourst" Subject: Re: Xen cpufreq support status: how to notify hypervisor of frequency change? Date: Wed, 12 Apr 2006 22:31:17 -0400 Message-ID: <200604122231.17561.yourst@yourst.com> References: <200604081829.00179.yourst@yourst.com> <200604111611.42604.yourst@yourst.com> <367ff4cc58e23ff395b7944b7b28b35b@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <367ff4cc58e23ff395b7944b7b28b35b@cl.cam.ac.uk> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wednesday 12 April 2006 01:47 am, you wrote: > > local_time_calibration() won't really do the right thing. It will > calibrate for the observed TSC rate over the last few seconds, most of > which will have passed at the old TSC rate. The simplest fix would > simply be to multiply the calculated TSC scale factor by > new_mhz/old_mhz. Doesn't set_time_scale() do exactly this by directly using the supplied ticks_per_sec value? Why does it need to be scaled based on the old frequency when the values can just be recalculated? I removed the call to local_time_calibration() and it still works just fine, so it looks like set_time_scale() overrides the other settings anyway. I'm still having a strange issue (only in X sessions it appears) where the key repeat rate and response time gets very slow after a frequency shift. Everything else responds normally except for the keyboard, and that problem goes away after a minute or two. Any idea what's going on? - Matt ------------------------------------------------------- Matt T. Yourst yourst@cs.binghamton.edu Binghamton University, Department of Computer Science -------------------------------------------------------