RE: [Xen-devel] Re: TSC scaling and softtsc reprise, and PROPOSAL

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Oops, forgot to add...

>>>Linux will use the tsc where possible, but regularly
>>>assesses its

"Regularly assesses" is a big misleading... according
to my reading of the 2.6.30 code, it checks for "good
synchronization" once at boot, then after that only
ensures that things haven't gone completely whacko
by checking that multiple TSCs haven't diverged by
more than ~60msec(?).  While I suppose this will catch
the most likely divergent hardware cases, I suspect
Xen's periodically-attempt-to-sync-the-TSC code might
lull the linux kernel into complacency (and 60msec
accuracy is just not good enough for applications).

> -----Original Message-----
> From: Dan Magenheimer 
> Sent: Thursday, August 06, 2009 3:13 PM
> To: Tian, Kevin; Jeremy Fitzhardinge; Keir Fraser
> Cc: Ian Pratt; Xen-Devel (E-mail); Dong, Eddie; Zhang, Xiantao; John
> Levon
> Subject: RE: [Xen-devel] Re: TSC scaling and softtsc reprise, and
> PROPOSAL
> 
> 
> Well actually, "how Linux handles this" is subject to
> a dizzying matrix of hardware-dependent, CONFIG_-dependent,
> linux-boot-parameter-dependent choices
> that have evolved/changed at nearly every Linux
> kernel version.  While it might be useful to steal
> some recent Linux code to help determine if it is
> safe to build Xen system time on top of TSC on some
> processors, I don't know if Linux is of much use as
> a design guide for how to expose TSC to guests/apps,
> especially when said guests/apps may be moving back and
> forth between hardware with widely varying TSC
> characteristics.
> 
> But, yes, as Kevin points out, on some recent versions
> of Linux on some hardware with some CONFIG/boot-params,
> the kernel does indeed try to use TSC as a reliable
> foundation for delivering ticks and gettimeofday-ish
> services.
> 
> > -----Original Message-----
> > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> > Sent: Tuesday, August 04, 2009 11:36 PM
> > To: Jeremy Fitzhardinge; Keir Fraser
> > Cc: Dan Magenheimer; Xen-Devel (E-mail); Dong, Eddie; John
> > Levon; Ian Pratt; Zhang, Xiantao
> > Subject: RE: [Xen-devel] Re: TSC scaling and softtsc reprise,
> > and PROPOSAL
> >
> >
> > >From: Jeremy Fitzhardinge
> > >Sent: 2009?8?5? 8:06
> > >
> > >On 07/24/09 01:04, Keir Fraser wrote:
> > >> Okay, so the issue you are worried about is not specific to
> > >Xen. So how is
> > >> native Linux tackling this, for example?
> > >>  
> > >
> > >Linux will use the tsc where possible, but regularly assesses its
> > >perceived accuracy and will move to a different clocksource
> > if the tsc
> > >appears to the playing up.  I don't think it ever assumes 
> the tsc is
> > >synced between CPU/cores.
> >
> > It cares. See tsc_sync.c under x86 arch, where unsynced warps
> > mark tsc as unstable.
> >
> > Thanks,
> > Kevin
> >
> > >
> > >It allows rdtsc from usermode, but it is generally considered
> > >to be very
> > >buggy and ill-defined behaviour.  It makes no attempt to
> > make usermode
> > >rdtsc in any way meaningful.  The exception is the vgettimeofday
> > >vsyscall which does Xen-like timekeeping, in which it gets
> > the tsc,cpu
> > >tuple atomically, then scales it with timing parameters from
> > >the kernel.
> > >
> > >    J
> > >
> > >_______________________________________________
> > >Xen-devel mailing list
> > >Xen-devel@xxxxxxxxxxxxxxxxxxx
> > >http://lists.xensource.com/xen-devel
> > >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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