This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-ia64-devel] Question about migration

On Tue, 2008-02-05 at 21:54 +0800, Dong, Eddie wrote:
> > 
> >   The kernel guarantees applications only see time move forward, even
> > across multiple CPUs.  See: 
> > 
> > kernel/timer.c:time_interpolator_get_counter()
> > 
> > We never return a time before last_cycle unless booted with the
> > "nojitter" options. 
> > 
> Echo from me too.
> I was told some time ago, the crystal used in IPF platform is usually
> expansive
> than other platforms and thus much more accurate.
> Normally the small difference won;t cause application see backward ITC
> value,
> but live migration per current Xen time virtualization policy is another
> story. It
> could be a headache :(

   IMHO, an application that uses the ITC directly is asking for
problems.  There's no guarantee to the application that the OS does
anything to synchronize the ITCs, or even that they're used by the
kernel for timekeeping.  Platforms like the SGI Altix have drifty ITCs
and use other means for time keeping.  It's not uncommon for platforms
to have HPETs today.  For time keeping, these often have higher latency
than the ITC, but there are potential benefits when using them on large
systems because you don't need the cmpxchg to ensure time goes forward.
Maybe a paravirt guest should run with PSR.SI set to ensure applications
aren't making bad assumptions.

   BTW, it looks like jitter protection code moved to
arch/ia64/kernel/time.c:itc_get_cycles in newer kernels.


Alex Williamson                             HP Open Source & Linux Org.

Xen-ia64-devel mailing list