From: David Miller <davem@davemloft.net>
To: steiner@sgi.com
Cc: mingo@elte.hu, raz@scalemp.com, linux-kernel@vger.kernel.org,
mingo@redhat.com, a.p.zijlstra@chello.nl, efault@gmx.de,
cpw@sgi.com, travis@sgi.com, tglx@linutronix.de, hpa@zytor.com
Subject: Re: [BUG] soft lockup while booting machine with more than 700 cores
Date: Thu, 10 Feb 2011 13:03:25 -0800 (PST) [thread overview]
Message-ID: <20110210.130325.112603217.davem@davemloft.net> (raw)
In-Reply-To: <20110210205648.GA10341@sgi.com>
From: Jack Steiner <steiner@sgi.com>
Date: Thu, 10 Feb 2011 14:56:48 -0600
> We also noticed that the rebalance_domains() code references many per-cpu
> run queue structures. All of the structures have identical offsets relative
> to the size of a cache leaf. The result is that all index into the same lines in the
> L3 caches. That causes many evictions. We tried an experimental to
> stride the run queues at 128 byte offsets. That helped in some cases but the
> results were mixed. We are still experimenting with the patch.
I think chasing after cache alignment issues misses the point entirely.
The core issue is that rebalance_domains() is insanely expensive, by
design. It's complexity is N factorial for the idle non-HZ cpu that is
selected to balance every single domain.
A statistic datastructure that is approximately 128 bytes in size is
repopulated N! times each time this global rebalance thing runs.
I've been seeing rebalance_domains() in my perf top output on 128 cpu
machines for several years now. Even on an otherwise idle machine,
the system churns in thus code path endlessly.
next prev parent reply other threads:[~2011-02-10 21:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 7:27 raz ben yehuda
2011-02-10 4:47 ` Mike Galbraith
2011-02-10 12:39 ` Ingo Molnar
2011-02-10 6:09 ` raz ben yehuda
2011-02-10 20:56 ` Jack Steiner
2011-02-10 21:03 ` David Miller [this message]
2011-02-10 21:12 ` Jack Steiner
2011-02-16 15:04 ` Dimitri Sivanich
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=20110210.130325.112603217.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=a.p.zijlstra@chello.nl \
--cc=cpw@sgi.com \
--cc=efault@gmx.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=raz@scalemp.com \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=travis@sgi.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
all inboxes | Powered by JetHome®