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

RE: [Xen-devel] Re: [PATCH] clocksource=tsc



> > So perhaps the compromise which I've (admittedly accidentally)
> > crafted is the right answer for now.  And the right answer for
> > later is to update the PV time mechanisms (in a backwards
> > compatible way of course) to determine if an ideal timesource
> > is available and use it if it is.
> 
> Well, maybe, although I don't see we have any guarantee that 'platform
> system time' and Xen's get_s_time won't diverge in absolute 
> terms as time
> passes. The scale factors each use are calculated somewhat 
> independently.
> Actually I think it may get it right just now, but it looks 
> rather fragile
> and it stores up trouble for systems with long uptimes if you 
> get it wrong.
> There's no particular reason not to generate fresh time 
> records every few
> seconds and use those both in Xen and in guests, using the existing
> compute-system-time algorithm.

It appears that, for clocksource=tsc, as long as both
read_platform_stime() and get_s_time() are returning
scaled-tsc there can be no divergence.

The issue with generating fresh time records every
few seconds is that it unnecessarily introduces jitter
into an otherwise ideal timesource.

Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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