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] Still Time went backwards problems Xen 3.3.1/2.6.18.8

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Still Time went backwards problems Xen 3.3.1/2.6.18.8
From: "Carsten Schiers" <carsten@xxxxxxxxxx>
Date: Sat, 7 Mar 2009 10:41:46 +0100
Cc: "mark.langsdorf" <mark.langsdorf@xxxxxxx>, "keir.fraser" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sat, 07 Mar 2009 01:42:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6453C3CB8E2B3646B0D020C112613273C5AE46@xxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Still have problems with "Time went backwards" messages. Now I am nearly 
completely at
Xen 3.3.1 and Xen kernel 2.6.18.8 for Dom0 and nearly all DomUs. There 
is only one DomU
That is on a customized special kernel for Endian (2.6.21.7-2).

Q1: Can a DomU kernel version anyhow be responsible for that effect?

Attached you can see the last two days. I noticed that they occur every 
five minutes, 
so it's probably connected with the munin cron job that collects xen 
domain usage and
cpufreq-stats. Nothing more. Delta is still quite huge, around 40 ms. 
Value is negative.

Q2: Is that any better than if it's positive?
Q3: Will the delta be reset or will it go up and down all the time?

Currently I use both cpufreq=dom0 and cpuidle. 

Q4: Can the problem eventually be related to either of them only?

Right now, I disabled cpuidle for the time being, to see whether there 
is a difference.
If not, I intend to use xen-unstable next. I attached the current xm 
dmesg and xm info,
so don't be surprised to miss cpuidle.

Well, I am not sure whether I do too much work on this issue, but I 
think the log message
is there for a reason. 

Best Regards,
Carsten.

P.S.: There are combinations that are much worse that this. Especially 
running Xen 3.3.1
and actual Lenny kernel seems to be worse.

-----Ursprüngliche Nachricht-----
Von: Langsdorf, Mark [mailto:mark.langsdorf@xxxxxxx] 
Gesendet: Donnerstag, 15. Januar 2009 20:27
An: Carsten Schiers
Betreff: RE: RE: RE: RE: [Xen-devel] AMD P-States not recognized for Xen 
3.3 and 3.4

If you have a single socket system, then fixing the
out of sync issue will probably not fix the TSC issue.

If you have a dual or quad socket system, fixing the
out of sync error should reduce the frequency and
magnitude of the TSC issues.  At least, that's the
best I can decipher from my notes.

Also, most of the work I did on cpufreq was in 2007, 
before Dan M. greatly redid Xen hypervisor time-keeping.
If an up-to-date kernel/hypervisor still has TSC problems,
it may be possible to fix them.  I don't really have 
time to research it myself, but if you do have problems, 
please contact me and I'll see what can be done.

-Mark Langsdorf
Operating System Research Center
AMD

> -----Original Message-----
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx] 
> Sent: Thursday, January 15, 2009 1:17 PM
> To: Langsdorf, Mark
> Subject: AW: RE: RE: RE: [Xen-devel] AMD P-States not 
> recognized for Xen 3.3 and 3.4
> 
> Thanks Mark, don't want to get on your nerve, but this will 
> only fix the
> powernow-k8 out of synch issue but not the fact that my 4050e 
> will have
> TSC issues between the two cores when switching frequencies, right? 
> 
> Am I right that there is no cure for that currently? And that 
> I am not 
> safe
> to ignore them, because some kernel wizard is synchronizing 
> them? 'Cause
> up to now I only found a synch in boot.c.
> 
> Sorry for all those questions, it's quite complicated. My 
> best times as
> code producer habe been some 15 years ago...
> 
> Thanks,
> Carsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: Langsdorf, Mark [mailto:mark.langsdorf@xxxxxxx] 
> Gesendet: Donnerstag, 15. Januar 2009 18:23
> An: Carsten Schiers
> Betreff: RE: RE: RE: [Xen-devel] AMD P-States not recognized 
> for Xen 3.3 
> and 3.4
> 
> > Thank you Mark. Please excuse my small knowledge in 
> > kernel/xen hacking.  I understood that I should either 
> > 
> >   a) create a build of the actual xen-unstable.hg together with 
> > linux-2.6.18-xen.hg kernel (where you think to have fixed 
> the problem)
> >
> > or 
> > 
> >   b) to include the mentioned fixes into my environment 
> (which is the 
> > 3.2.1 Xen and Bastian Blank's (waldi) kernel (based on 2.6.18, too),
> > right?
> > 
> > I'll try out what will be more easy, but I think it should be a).
> 
> Right.  Using the latest unstable kernel & hypervisor gives
> you all the patches.  If you're backporting support into
> the waldi kernel, you need to make sure you backport all
> the relevant patches.
> 
> -Mark Langsdorf
> Operating System Research Center
> AMD
> 
> 
> 
> 
> 



Attachment: log.txt
Description: Binary data

Attachment: xmdmesg.txt
Description: Binary data

Attachment: xminfo.txt
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>