[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |