Re: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 05/12/2008 11:50, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> That's why we go with option d) which really exposes same level
> of constraints compared to disabled case. This is not perfect
> solution, but it shows more stable result than others.

It does depend on constant_tsc though. That's fine, but I think then it
should be implemented as an alternative method selected only when you detect
constant_tsc at runtime. The fallback should be something like Gang Wei
posted most recently.

Also don't use cpu_khz as it's way less accurate than you need to put up
with. Create a 'struct time_scale' that will convert from nanoseconds to TSC
ticks. I think a reciprocal function for time_scale's would be useful here
(and in Gang Wei's last patch as well) as then you can take the existing
initial TSC->ns scale and flip it.

The other concern I have is that, even with a much more accurate scale
factor, CPUs which do not enter deep-C (because they are running busy loops
for example) will *slowly* wander from the time line determined by your
scale factor (due to unavoidable imprecision in the scale factor). This
could build up to be noticeable over days. It might be an idea therefore to
occasionally force a TSC resync on any CPU that hasn't had it resynced for
other reasons, just to zap any accumulating imprecision that has crept in.
It'd only need to be done maybe once a minute or maybe even much less than
that.

 -- Keir




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