All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Anderson <rja@sgi.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Robin Holt <holt@sgi.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH] Do not force shutdown/reboot to boot cpu.
Date: Wed, 10 Apr 2013 18:02:35 -0500	[thread overview]
Message-ID: <20130410230234.GB8112@sgi.com> (raw)
In-Reply-To: <20130410165934.GB21951@gmail.com>

On Wed, Apr 10, 2013 at 06:59:34PM +0200, Ingo Molnar wrote:
> * Russ Anderson <rja@sgi.com> wrote:
> 
> > Yes, I have a test patch that replaces for_each_online_cpu(cpu) with a cpu 
> > bitmask in disable_nonboot_cpus().  The lower level routines already take a 
> > bitmask.  It allows __stop_machine() to be called just once.  That change 
> > reduces shutdown time on a 1024 cpu machine from 16 minutes 4 minutes.  
> > Significant improvement, but not good enough.
> > 
> > The next significant bottleneck is __cpu_notify().  Tried creating worker 
> > threads to parallelize the shutdown, but the problem is __cpu_notify() is not 
> > thread safe.  Putting a lock around it caused all the worker threads to fight 
> > over the lock.
> 
> 4 minutes bootup is 240 seconds, with 1024 CPUs that's about 240 msecs per CPU.
> 
> That sounds a lot, given that unlike bootup there's not much real work to be done 
> during shutdown - we don't initialize anything, etc.
> 
> Maybe much of those 240 msecs are spent in some stupid udelay loop or so, which 
> could be made parallel?

I was hoping for a stupid udelay when I first started looking
at this code, but found nothing obvious.

The bulk of the time (after making the cpu bitmask change) is
spent in __cpu_notify(), as explained above.


> Would it be possible to create a 'reboot but stop at the end and reactivate all 
> CPUs again' reboot flag, so that it can all be NMI-profiled, to see where the true 
> bottleneck is? A naked disable_nonboot_cpus() call in essence.

My testing was similar.  I hacked a kernel module to call
disable_nonboot_cpus() and enable_nonboot_cpus() and used
printks to narrow down the slow functions.  That points
at the cpu notifier call chain.  It's not clear if any
of the functions on the call chain take a long time, or
just going sequentially through the list for all cpus just
takes a long time.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

  parent reply	other threads:[~2013-04-10 23:02 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 19:37 [PATCH] Do not force shutdown/reboot to boot cpu Robin Holt
2013-04-08 15:57 ` Ingo Molnar
2013-04-08 16:11   ` H. Peter Anvin
2013-04-08 16:59     ` Robin Holt
2013-04-10 11:16       ` Ingo Molnar
2013-04-10 14:01         ` Robin Holt
2013-04-10 15:10         ` Linus Torvalds
2013-04-10 15:29           ` Russ Anderson
2013-04-10 16:59             ` Ingo Molnar
2013-04-10 17:14               ` Robin Holt
2013-04-10 17:22                 ` Ingo Molnar
2013-04-10 17:55                   ` Robin Holt
2013-04-10 19:00                     ` Robin Holt
2013-04-11  8:57                       ` Ingo Molnar
2013-04-11 11:34                         ` Robin Holt
2013-04-11 12:00                           ` Ingo Molnar
2013-04-11 12:03                             ` Robin Holt
2013-04-11 12:08                               ` Robin Holt
2013-04-11 12:14                                 ` Ingo Molnar
2013-04-10 17:58               ` H. Peter Anvin
2013-04-10 23:02               ` Russ Anderson [this message]
2013-04-10 22:29             ` Russ Anderson
2013-04-11  5:31           ` Paul Mackerras
2013-04-11 12:45             ` Bulk CPU Hotplug (Was Re: [PATCH] Do not force shutdown/reboot to boot cpu.) Srivatsa S. Bhat
2013-04-11 13:48               ` Robin Holt
2013-04-12  5:37                 ` Ingo Molnar
2013-04-12  6:09                   ` Srivatsa S. Bhat
2013-04-12  9:31                     ` Robin Holt
2013-04-12 10:01                       ` Robin Holt
2013-04-13 16:30                       ` Oleg Nesterov
2013-04-15 16:04                         ` Robin Holt
2013-04-15 16:09                           ` Oleg Nesterov
2013-04-15 16:10                           ` Robin Holt
2013-04-13 17:01                       ` Srivatsa S. Bhat
2013-04-15 10:16                       ` Ingo Molnar
2013-04-15 12:02                         ` Robin Holt
2013-04-15 15:59                           ` Robin Holt
2013-04-16  9:40                             ` Ingo Molnar
2013-04-11 14:23               ` Russ Anderson
2013-04-11 14:45                 ` Srivatsa S. Bhat
2013-04-11 20:08                   ` Russ Anderson
2013-04-11 20:17                     ` Srivatsa S. Bhat
2013-04-11 21:08                     ` Robin Holt
2013-04-08 16:54   ` [PATCH] Do not force shutdown/reboot to boot cpu Robin Holt
2013-04-08 17:07   ` Russ Anderson

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=20130410230234.GB8112@sgi.com \
    --to=rja@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=holt@sgi.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=shawn.guo@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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.