All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Ackaouy <ackaouy@gmail.com>
To: "Carb, Brian A" <Brian.Carb@unisys.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Odd CPU Scheduling Behavior
Date: Thu, 29 Mar 2007 17:42:04 +0200	[thread overview]
Message-ID: <ac269497563576fac1573da5b4bd1800@gmail.com> (raw)
In-Reply-To: <B05D2E415E8CC94897BB44233D14EE68057B54C1@USTR-EXCH5.na.uis.unisys.com>

There is no gang scheduling in Xen so what you see is not unexpected.
Both VCPUs of the same VM are as likely to run on the same physical
CPU than not. For each VM though, both its VCPUs should get equal
CPU time if they are runnable even if they alternatively run on the same
physical CPU.

I have seen some multithreaded applications/libraries back off using
execution vehicles (processes) to schedule a runnable thread when
it doesn't seem to make forward progress, probably because some
code somewhere assumes another process is hogging the CPU and
it's therefore better to lower the number of execution vehicles. In this
case, multithreaded apps running on a 2CPU guest on Xen sometimes
only schedule work on 1CPU when there is another VM competing
for the physical CPU resources.

Are both VCPUs of each VM making forward progress during your test?

On Mar 29, 2007, at 16:58, Carb, Brian A wrote:

> We're seeing a cpu scheduling behavior in Xen and we're wondering if 
> anyone can explain it.
>  
> We're running XEN 3.0.4 on a Unisys ES7000/one with 8 CPUs (4 
> dual-core sockets) and 32GB memory. XEN is built on SLES10, and the 
> system is booted with dom0_mem=512mb. We have 2 para-virtual machines, 
> each booted with 2 vcpus and 2GB memory, and each running SLES10 and 
> Apache2 with worker multi-processing modules.
>  
> The vcpus of dom0, vm1 and vm2 are pinned as follows:
>  
> dom0 is relegated to 2 vcpus (xm vcpu-set 0 2) and these are pinned to 
> cpus 0-1
> vm1 uses 2 vcpus pinned to cpus 2-3
> vm2 uses 2 vcpus pinned to cpus 2-3
>  
> The cpus 4 through 7 are left unused.
>  
> Our test runs http_load against the Apache2 web servers in the 2 vms. 
> Since Apache2 is using worker multi-processing modules, we expect that 
> each vm will spread its load over the 2 vcpus, and during the test we 
> have verified this using top and sar inside a vm console.
>  
> The odd behavior occurs when we monitor cpu usage using xenmon in 
> interactive mode. By pressing "c", we can observe the load on each of 
> the cpus. When we examine cpus 2 and 3 initially, each is used equally 
> by vm1 and vm2. However, shortly after we start our testing, cpu2 runs 
> vm1 exclusively 100% of the time, and cpu3 runs vm2 100% of the time.  
> When the test completes, CPUs 2 and 3 go back to sharing the load of 
> vm1 and vm2.
>  
> Is this the expected behavior?
>
> brian carb
> unisys corporation - malvern, 
> pa_______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  reply	other threads:[~2007-03-29 15:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-29 14:58 Odd CPU Scheduling Behavior Carb, Brian A
2007-03-29 15:42 ` Emmanuel Ackaouy [this message]
2007-03-29 15:57   ` Carb, Brian A
2007-03-29 16:03     ` Petersson, Mats
2007-03-29 16:29       ` Apparao, Padmashree K
2007-03-30 10:12     ` Emmanuel Ackaouy
2007-04-02 18:04       ` Carb, Brian A

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=ac269497563576fac1573da5b4bd1800@gmail.com \
    --to=ackaouy@gmail.com \
    --cc=Brian.Carb@unisys.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.