Re: softtsc for PV guests

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 08/23/09 09:42, Dan Magenheimer wrote:
> While I'm hoping that this is true, I am skeptical.  The
> PV time algorithm does depend on TSC accuracy for interpolating
> over short intervals doesn't it?
>   

Yes, it extrapolates, assuming that in the absence of power events, etc,
the tsc is stable over a period of a few seconds on a given CPU.

> Assuming an SMP PV guest starts on a machine with "safe TSC" (e.g. a
> recent multi-core single-socket) and migrates successively to
> a sequence of machines with:
>
> 1) a multi-socket where TSCs are not synchronized and skew badly
> 2) a different multi-core single-socket with a faster TSC frequencey
> 3) a multi-core/socket where TSC frequency varies according to
>    per-cpu power-saving configuration
>
> does the SMP PV guest maintain time properly?
>   

It uses timing parameters from Xen.  If Xen can't keep track of the tsc
and events which affect it and provides bad info, it will fail.  But
then it means that Xen can't use the tsc internally either, so
presumably won't be able to accurately emulate it either.  The ABI never
assumes that the tsc is synchronized between CPUs, or that they're
running at even approximately the same rate.

The main risk is having the CPU asynchronously change speed under Xen,
with either no notification or a delayed notification (like thermal
events).  Any synchronous speed change can be dealt with.

> And even if it does, this doesn't help applications that read
> TSC directly (which, admittedly, they shouldn't, but since
> the processor vendors have made TSC much "safer" on most
> systems, which will probably soon account for >90% of systems
> shipped, SMP app direct use of TSC will likely become more prevalent.)
>   

Right.  That's basically not supported under Linux, except as part of
certain ABIs like vgettimeofday (which is functionally identical to the
Xen PV clock ABI).

> It's dom0.  I do see get an IP but it varies pretty widely from
> sample (of '0') to sample and I haven't tried a symbol lookup
> yet because I fear they will be buried in layers of block drivers
>
> I'm still hoping for some clue without digging that deep...
> All I've presumably done (assuming my patch doesn't have a weird
> bug) is make rdtsc slower.
>   

It's presumed to be fast in a number of places, but it shouldn't cause
it to fail.  Maybe some race is coming up.  If you just revert the
register write to make rdtsc trap, does it still hang?

    J