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

["Wei, Gang" <gang.wei@xxxxxxxxx>]

On Monday, December 15, 2008 8:03 PM, Keir Fraser wrote:
> On 15/12/2008 09:40, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
> 
>> Redo the constant_tsc & tsc_nostop check part and post it again.
> 
> I applied the bits outside time.c. For time.c itself, how about the simpler
> attached alternative? Does it work well? :-)

Although it looks simpler & workable, but the practice shows it doesn't work. 

The phenomena:

A) xm vcpu-list shows weird number, & cpu 1 looks like dead-locked.

[root@lke_linux_mv ~]# xm vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0     0   r--     124.8 any cpu
Domain-0                             0     1     0   ---  7281029792.3 any cpu
LinuxHVMDomain_1                     1     0     0   ---      37.5 any cpu
LinuxHVMDomain_2                     3     0     0   ---      45.5 any cpu
LinuxHVMDomain_3                     4     0     1   r--       4.1 any cpu
LinuxHVMDomain_4                     2     0     0   ---      41.9 any cpu

The dump info of cpu1:

(XEN) Xen call trace:
(XEN)    [<ffff828c8010ca71>] __dump_execstate+0x1/0x60
(XEN)    [<ffff828c8014f66d>] smp_call_function_interrupt+0x7d/0xd0
(XEN)    [<ffff828c8013b41a>] call_function_interrupt+0x2a/0x30
(XEN)    [<ffff828c80151538>] get_s_time+0x28/0x70
(XEN)    [<ffff828c8017fa0a>] hvm_get_guest_time+0x3a/0x90
(XEN)    [<ffff828c8017d620>] pmt_timer_callback+0x0/0x80
(XEN)    [<ffff828c8017d4fc>] pmt_update_time+0x1c/0x70
(XEN)    [<ffff828c8017d620>] pmt_timer_callback+0x0/0x80
(XEN)    [<ffff828c8017d649>] pmt_timer_callback+0x29/0x80
(XEN)    [<ffff828c80118ebc>] execute_timer+0x2c/0x50
(XEN)    [<ffff828c80118ffa>] timer_softirq_action+0x11a/0x2d0
(XEN)    [<ffff828c801175b0>] do_softirq+0x70/0x80
(XEN)    [<ffff828c80188915>] vmx_asm_do_vmentry+0xd2/0xdd
(XEN)
(XEN) *** Dumping CPU1 guest state: ***
(XEN) ----[ Xen-3.4-unstable  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    f000:[<000000000000054f>]
(XEN) RFLAGS: 0000000000000202   CONTEXT: hvm guest
(XEN) rax: 00000000000001f7   rbx: 0000000000000000   rcx: 0000000000000000
(XEN) rdx: 00000000000001f7   rsi: 00000000000058b0   rdi: 0000000000003400
(XEN) rbp: 0000000000001f7a   rsp: 0000000000001f78   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 0000   es: 7000   fs: 0000   gs: 0000   ss: 0000   cs: f000
(XEN)

B) the tsc skew become larger and larger

(XEN) Synced stime skew: max=54879663ns avg=54529587ns samples=93 
current=54879663ns
(XEN) Synced cycles skew: max=113678958 avg=112788173 samples=93 
current=113678958
(XEN) Synced stime skew: max=54881161ns avg=54533327ns samples=94 
current=54881161ns
(XEN) Synced cycles skew: max=113682743 avg=112797689 samples=94 
current=113682743
(XEN) Synced stime skew: max=54882749ns avg=54537006ns samples=95 
current=54882749ns
(XEN) Synced cycles skew: max=113686776 avg=112807048 samples=95 
current=113686776

> 
> Notice I don't reset TSCs at all (except when !NOSTOP_TSC and after deep
> sleep).
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel