From: Micah Dowty <micah@vmware.com>
To: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Christoph Lameter <clameter@sgi.com>,
Kyle Moffett <mrmacman_g4@mac.com>,
Cyrus Massoumi <cyrusm@gmx.net>,
LKML Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Mike Galbraith <efault@gmx.de>,
Paul Menage <menage@google.com>,
Peter Williams <pwil3058@bigpond.net.au>
Subject: Re: High priority tasks break SMP balancer?
Date: Wed, 21 Nov 2007 23:46:52 -0800 [thread overview]
Message-ID: <20071122074652.GA6502@vmware.com> (raw)
In-Reply-To: <b647ffbd0711201347tedf7ac0sc6476118353feab3@mail.gmail.com>
On Tue, Nov 20, 2007 at 10:47:52PM +0100, Dmitry Adamushko wrote:
> btw., what's your system? If I recall right, SD_BALANCE_NEWIDLE is on
> by default for all configs, except for NUMA nodes.
It's a dual AMD64 Opteron.
So, I recompiled my 2.6.23.1 kernel without NUMA support, and with
your patch for scheduling domain flags in /proc. It looks like with
NUMA disabled, my test case no longer shows the CPU imbalance
problem. Cool.
With NUMA disabled (and my test running smoothly), the flags show that
SD_BALANCE_NEWIDLE is set:
root@micah-64:~# cat /proc/sys/kernel/sched_domain/cpu0/domain0/flags
55
Next I turned it off:
root@micah-64:~# echo 53 > /proc/sys/kernel/sched_domain/cpu0/domain0/flags
root@micah-64:~# echo 53 > /proc/sys/kernel/sched_domain/cpu1/domain0/flags
Oddly enough, I still don't observe the CPU imbalance problem.
Now I reboot into a kernel which has NUMA re-enabled but which is
otherwise identical. I verify that now I can reproduce the CPU
imbalance again.
root@micah-64:~# cat /proc/sys/kernel/sched_domain/cpu0/domain0/flags
1101
Now I set cpu[10]/domain0/flags to 1099, and the imbalance immediately
disappears. I can reliably cause the imbalance again by setting it
back to 1101, and remove the imbalance by setting them to 1099.
Do these results make sense? I'm not sure I understand how
SD_BALANCE_NEWIDLE could be the whole story, since my /proc/schedstat
graphs do show that we continuously try to balance on idle, but we
can't successfully do so because the idle CPU has a much higher load
than the non-idle CPU. I don't understand how the problem I'm seeing
could be related to the time at which we run the balancer, rather than
being related to the load average calculation.
Assuming the CPU imbalance I'm seeing is actually related to
SD_BALANCE_NEWIDLE being unset, I have a couple of questions:
- Is this intended/expected behaviour for a machine without
NEWIDLE set? I'm not familiar with the rationale for disabling
this flag on NUMA systems.
- Is there a good way to detect, without any kernel debug flags
set, whether the current machine has any scheduling domains
that are missing the SD_BALANCE_NEWIDLE bit? I'm looking for
a good way to work around the problem I'm seeing with VMware's
code. Right now the best I can do is disable all thread priority
elevation when running on an SMP machine with Linux 2.6.20 or
later.
Thank you again for all your help.
--Micah
next prev parent reply other threads:[~2007-11-22 7:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 22:34 High priority tasks break SMP balancer? Micah Dowty
2007-11-09 23:56 ` Cyrus Massoumi
2007-11-10 0:11 ` Micah Dowty
2007-11-14 18:39 ` Micah Dowty
2007-11-15 18:48 ` Kyle Moffett
2007-11-15 19:14 ` Micah Dowty
2007-11-15 20:07 ` Christoph Lameter
2007-11-15 20:24 ` Micah Dowty
2007-11-15 21:28 ` Christoph Lameter
2007-11-15 21:35 ` Micah Dowty
2007-11-16 2:31 ` Christoph Lameter
2007-11-16 2:44 ` Micah Dowty
2007-11-16 6:07 ` Ingo Molnar
2007-11-16 9:19 ` Micah Dowty
2007-11-16 10:45 ` Ingo Molnar
2007-11-16 10:48 ` Micah Dowty
2007-11-16 22:12 ` Christoph Lameter
2007-11-16 10:48 ` Dmitry Adamushko
2007-11-16 22:14 ` Micah Dowty
2007-11-16 23:26 ` Dmitry Adamushko
2007-11-17 1:03 ` Micah Dowty
2007-11-17 19:10 ` Dmitry Adamushko
2007-11-19 18:51 ` Micah Dowty
2007-11-19 22:22 ` Dmitry Adamushko
2007-11-19 23:05 ` Micah Dowty
2007-11-20 5:57 ` Ingo Molnar
2007-11-20 18:06 ` Micah Dowty
2007-11-20 21:47 ` Dmitry Adamushko
2007-11-22 7:46 ` Micah Dowty [this message]
2007-11-22 12:53 ` Dmitry Adamushko
2007-11-26 19:44 ` Micah Dowty
2007-11-27 9:21 ` Dmitry Adamushko
2007-11-27 17:13 ` Micah Dowty
2007-11-16 19:13 ` David Newall
2007-11-16 21:38 ` Micah Dowty
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=20071122074652.GA6502@vmware.com \
--to=micah@vmware.com \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=cyrusm@gmx.net \
--cc=dmitry.adamushko@gmail.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mingo@elte.hu \
--cc=mrmacman_g4@mac.com \
--cc=pwil3058@bigpond.net.au \
/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.