WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big ts

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Fri, 5 Dec 2008 17:21:04 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Fri, 05 Dec 2008 01:21:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C55E9C9D.1FE03%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8FED46E8A9CA574792FC7AACAC38FE7701C589A53D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C55E9C9D.1FE03%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclWoeM2xc+X6mj6QOaQHsyxDmpzagAFRoNpAACb7OA=
Thread-topic: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
On Friday, December 05, 2008 4:54 PM, Keir Fraser wrote:
> On 05/12/2008 06:22, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
> 
>> Originally, the sequence for each cpu is [tsc-save, entry deepC, break-evt,
>> exit deepC, tsc-restore], the system error is quite easy to be accumulated.
>> Once the workloads between cpus are not balanced, the tsc skew between cpus
>> will eventually become bigger & begger - more than 10 seconds can be
>> observed. 
>> 
>> Now, we just keep a initial stamp via cstate_init_stamp during the booting/s3
>> resuming, which is based on the platform stime. All cpus need only to do
>> tsc-restore relative to the initial stamp after exit deepC. The base is
>> fixed, and is the same for all cpus, so it can avoid accumulated tsc-skew.
>> 
>> Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
> 
> Synchronising to a start-of-day timestamp and extrapolating with cpu_khz is
> not a good idea because of the inherent accumulating inaccuracy in cpu_khz
> (it only has a fixed number of bits of precision). So, for example, if
> certain CPUs have not deep-C-slept for a long while, they will wander from
> your 'true' TSC values and then you will see TSC mismatches when the CPU
> does eventually C-sleep, or compared with other CPUs when they do so.
> 
> More significantly, cpu_khz is no good as a fixed static estimate of CPU
> clock speed when we start playing with P states.
> 
> I think your new code structure is correct. That is, work out wakeup TSC
> value from read_platform_stime() rather than some saved TSC value. However,
> you should extrapolate from that CPU's own t->stime_local_stamp,
> t->tsc_scale, and t->local_tsc_stamp. It's probably a pretty simple change
> to your new cstate_restore_tsc().
> 
> You see what I mean?

I tried extrapolating from t->stime_local_stamp, cpu_khz, and 
t->local_tsc_stamp before I got into the current solution. It would still bring 
accumulating skew, but in a slower increasing speed. I would like to try it 
again with  t->tsc_scale instead of cpu_khz. If it is works, it would really be 
simpler. Allow me some time.

Jimmy

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