xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
To: xen-devel@lists.xensource.com
Subject: Scheduling anomaly with 4.0.0 (rc6)
Date: Fri, 2 Apr 2010 09:48:49 -0700 (PDT)	[thread overview]
Message-ID: <3b511656-ea50-4ebb-918e-e24b40080580@default> (raw)

I've been running some heavy testing on a recent Xen 4.0
snapshot and seeing a strange scheduling anomaly that
I thought I should report.  I don't know if this is
a regression... I suspect not.

System is a Core 2 Duo (Conroe).  Load is four 2-VCPU
EL5u4 guests, two of which are 64-bit and two of which
are 32-bit.  Otherwise they are identical.  All four
are running a sequence of three Linux compiles with
(make -j8 clean; make -j8).  All are started approximately
concurrently: I synchronize the start of the test after
all domains are launched with an external NFS semaphore
file that is checked every 30 seconds.

What I am seeing is a rather large discrepancy in the
amount of time consumed "underway" by the four domains
as reported by xentop and xm list.  I have seen this
repeatedly, but the numbers in front of me right now are:

1191s dom0
3182s 64-bit #1
2577s 64-bit #2 <-- 20% less!
4316s 32-bit #1
2667s 32-bit #2 <-- 40% less!

Again these are identical workloads and the pairs
are identical released kernels running from identical
"file"-based virtual block devices containing released
distros.  Much of my testing had been with tmem and
self-ballooning so I had blamed them for awhile,
but I have reproduced it multiple times with both
of those turned off.

At start and after each kernel compile, I record
a timestamp, so I know the same work is being done.
Eventually the workload finishes on each domain and
intentionally crashes the kernel so measurement is
stopped.  At the conclusion, the 64-bit pair have
very similar total CPU sec and the 32-bit pair have
very similar total CPU sec so eventually (presumably
when the #1's are done hogging CPU), the "slower"
domains do finish the same amount of work.  As a
result, it is hard to tell from just the final
results that the four domains are getting scheduled
at very different rates.

Does this seem like a scheduler problem, or are there
other explanations? Anybody care to try to reproduce it?
Unfortunately, I have to use the machine now for other
work.

P.S. According to xentop, there is almost no network
activity, so it is all CPU and VBD.  And the ratio
of VBD activity looks to be approximately the same
ratio as CPU(sec).

             reply	other threads:[~2010-04-02 16:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-02 16:48 Dan Magenheimer [this message]
2010-04-05 14:43 ` Scheduling anomaly with 4.0.0 (rc6) George Dunlap
2010-04-05 20:17   ` Dan Magenheimer
2010-04-05 23:17     ` Dan Magenheimer
     [not found]     ` <5f8d4884-9b42-4457-a2da-cf679baa50bf@default q2sde76405a1004060423x84ec1662zeedc26f3ab54ad31@mail.gmail.com>
     [not found]       ` <q2sde76405a1004060423x84ec1662zeedc26f3ab54ad31@mail.gmail.com>
2010-04-06 16:51         ` Dan Magenheimer
2010-04-06 17:17           ` George Dunlap
2010-04-07 22:13           ` Dan Magenheimer

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=3b511656-ea50-4ebb-918e-e24b40080580@default \
    --to=dan.magenheimer@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).