From: Carsten Schiers <carsten@schiers.de>
To: "Tian, Kevin" <kevin.tian@intel.com>,
"keir.fraser" <keir.fraser@eu.citrix.com>,
xen-devel <xen-devel@lists.xensource.com>,
mark.langsdorf@amd.com
Subject: AW: AW: Re: AW: Re: Xen 3.4 strange behaviour as compared to Xen 3.3.1
Date: Wed, 3 Jun 2009 10:31:33 +0200 [thread overview]
Message-ID: <15103190.31244017893480.JavaMail.root@uhura> (raw)
Kevin, thanks, that fixed the issue of the ondemand govenor with cpufreq=dom0-kernel.
Keir, the other very strange issues (higher load when being the first DomU started, blocking
of /etc/init.d/xendomains when a certain DomU is first), I will try to investigate further
and post again when I have more information, so that this theat is not getting more complex.
BR,
Carsten.
----- Originalnachricht -----
Von: "Tian, Kevin" <kevin.tian@intel.com>
Gesendet: Mit, 3.6.2009 02:49
An: Carsten Schiers <carsten@schiers.de> ; keir.fraser <keir.fraser@eu.citrix.com> ; xen-devel <xen-devel@lists.xensource.com> ; mark.langsdorf@amd.com
Betreff: RE: AW: Re: AW: Re: [Xen-devel] Xen 3.4 strange behaviour as compared to Xen 3.3.1
>From: Carsten Schiers
>Sent: 2009年6月3日 0:18
>
>Sorry, I think it could also be that the CPU mask is somehow
>modified in the
>hypercall itself. Too much code for me to realy understand.
>
>Just a guess, but does Changeset 18898 take care of
>cpufreq=dom0-kernel case? It's
>patching the hypercall 52 and the cpufreq_ondemand.c of Xen
>near a modfication of
>a CPU mask variable, but no change in the cpufreq_ondemand.c
>of the Dom0 kernel.
>It also seems to fit into the time window, doesn't it?
>
That's really a silly typo. Could you try whether below fixes for you?
diff -r e8b74e981bfb xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c Tue Jun 02 18:58:09 2009 +0800
+++ b/xen/arch/x86/platform_hypercall.c Tue Jun 02 18:59:18 2009 +0800
@@ -313,7 +313,6 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
{
uint32_t cpu;
uint64_t idletime, now = NOW();
- struct vcpu *v;
struct xenctl_cpumap ctlmap;
cpumask_t cpumap;
XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
@@ -336,7 +335,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
for_each_cpu_mask ( cpu, cpumap )
{
- if ( (v = idle_vcpu[cpu]) != NULL )
+ if ( !idle_vcpu[cpu] )
cpu_clear(cpu, cpumap);
idletime = get_cpu_idle_time(cpu);
Thanks
Kevin
next reply other threads:[~2009-06-03 8:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 8:31 Carsten Schiers [this message]
2009-06-03 8:53 ` AW: AW: Re: AW: Re: Xen 3.4 strange behaviour as compared to Xen 3.3.1 Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15103190.31244017893480.JavaMail.root@uhura \
--to=carsten@schiers.de \
--cc=keir.fraser@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=mark.langsdorf@amd.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.