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] xen tsc problems?

On Tue, 13 Jul 2010, Dan Magenheimer wrote:
> > From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> > 
> > On 13/07/2010 15:37, "Stefano Stabellini"
> > <Stefano.Stabellini@xxxxxxxxxxxxx>
> > wrote:
> > 
> > > Does this mean that the host has some serious tsc issues?
> > > Can this be a symptom of a bug in xen?
> > > Suggestion are welcome.
> > 
> > The 's' and 't' debug key handlers will be useful to get an idea of how
> > stable host TSCs are.
> > 
> >  -- Keir
> 
> Also you can try max_cstate=0 as a Xen boot parameter to rule
> out power management screwing up the tsc.
> 
> > > Does this mean that the host has some serious tsc issues?
> 
> Probably.  But the default tsc_mode (0) is intended to hide all
> such issues.  Could you check the 's' debug-key output to
> ensure your guest is actually running with tsc_mode=0?
> 

this is the output of 's' and 't' without max_cstate=0:

(XEN) Synced stime skew: max=245ns avg=202ns samples=2 current=160ns
(XEN) Synced cycles skew: max=615 avg=577 samples=2 current=540 
(XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=0 
(count=2)                                         
(XEN) dom3(hvm): mode=0,ofs=0x2b2e19a77ea,khz=3000048,inc=1,vtsc count: 1211682 
total

this is the output of 's' and 't' with max_cstate=0:

(XEN) Synced stime skew: max=110ns avg=105ns samples=2 current=110ns
(XEN) Synced cycles skew: max=1020 avg=652 samples=2 current=285
(XEN) TSC has constant rate, no deep Cstates, passed warp test, deemed 
reliable, warp=0 (count=2)
(XEN) dom2(hvm): mode=0,ofs=0xb748091f5,khz=3000032,inc=1,vtsc count: 758954 
total

I still get the same warning from the guest.


I started to wonder why the guest is seeing such a big tsc warp when xen
is seeing 0, so I added more tracing and eventually I found out that the
value of v->arch.hvm_vcpu.stime_offset is significantly different
between the two vcpus and the difference increases after the scaling.
Then I added timer_mode=1 to my vm config file and the problem went
away.
I think that delay_for_missed_ticks shouldn't cause tsc scew in
the guest.



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

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