[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

  • To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 23 Jan 2008 23:06:42 +0000
  • Delivery-date: Wed, 23 Jan 2008 15:07:27 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchdJLibYAsM6tf0TQmN0NytQtkgrAAFoN6AAAFwnhMAJGZRIAAK2VqAAAAk5aAABASFcAABfrs0
  • Thread-topic: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

On 23/1/08 22:34, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx> wrote:

> Increasing the frequency requires (1) instructing the regulator to
> increasing the voltage, (2) waiting for it to settle, (3) increasing the
> multipler, (4) wait for the PLL to settle, (5) unpause the CPU.
> Which of these steps are under software control on PowerNow?
> Since we probably don't know how long we had to wait between when the
> multipler was increased and when the CPU was un-paused, it will be
> necessary to recalibrate the CPU to the global time source (PIT/HPET).

Yes, actually that is a good point. Possibly we would get better results by
setting t->stime_local_stamp = t->stime_master_stamp = read_platform_stime()
in xen/arch/x86/time.c:cpu_frequency_change(). Currently we set the local
stamp to get_s_time(), but get_s_time() may not be trustworthy.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.