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

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Mon, 15 Dec 2008 21:28:20 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Delivery-date: Mon, 15 Dec 2008 05:28:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C56BF7F6.CCA%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: <8FED46E8A9CA574792FC7AACAC38FE7701C7C99E64@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C56BF7F6.CCA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclWoeM2xc+X6mj6QOaQHsyxDmpzagAFRoNpAAEP6tAAAWmCgAAATdDsAAIJ5qAAAvL7GQFMKVOwAA1xISwAJTEgYAANxIuJAAtYh4AAAOh3kwBJ7/4QAAz5nPAABgajLwACXuJw
Thread-topic: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
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

<Prev in Thread] Current Thread [Next in Thread>