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

Re: [Xen-devel] [PATCH 7/10] linux 2.6.18: time handling

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Tue, 06 Mar 2007 11:38:04 +0000
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  • Delivery-date: Tue, 06 Mar 2007 03:37:21 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acdf4+bvJZeKfsvXEdueUQAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH 7/10] linux 2.6.18: time handling

On 5/3/07 11:17, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Remove struct timer_opts left-overs, add a Xen clocksource, and adjust
> conditionals for x86-64.
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

The other issue afaics is that the clocksource simply does raw reads of the
TSC, subsequently scaled by cpu_khz. This isn't very accurate and will cause
horrible problems if some CPUs enter power-saving modes (not explicitly
supported yet, but can happen due to auto thermal throttling) or on bigger
systems where TSCs may not be driven from the same mainboard clock (and
hence will drift).

I think Jeremy Fitzhardinge has an alternative clocksource patch which iirc
is more in line with how Xen time works (should advertise a GHz frequency
clocksource, and do scaling of the TSC value according to time-record values
read from shared_info). Having thought about this some more I think
clocksource support is worth getting into our tree, but let's look at both
available patches and decide which is the better basis for further work.

Jeremy: If I'm not mistaken and you do have a patch floating around, could
you post it?


Xen-devel mailing list



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