[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.