| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
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
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home