All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: David Miller <davem@davemloft.net>
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 15:12:23 -0600	[thread overview]
Message-ID: <20110210211223.GB10757@sgi.com> (raw)
In-Reply-To: <20110210.130325.112603217.davem@davemloft.net>

On Thu, Feb 10, 2011 at 01:03:25PM -0800, David Miller wrote:
> 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.

Completely agree! Idle rebalancing is also a big problem. We've seen
significant improvements on large systems in network thruput by
disabling IDLE load balancing for the higher (2 & 3) scheduling domains.

This is not a real fix but points to a problem.

--- jack

  reply	other threads:[~2011-02-10 21:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-09  7:27 [BUG] soft lockup while booting machine with more than 700 cores 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
2011-02-10 21:12       ` Jack Steiner [this message]
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=20110210211223.GB10757@sgi.com \
    --to=steiner@sgi.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cpw@sgi.com \
    --cc=davem@davemloft.net \
    --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=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 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.