All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Anderson <rja@sgi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.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 10:29:12 -0500	[thread overview]
Message-ID: <20130410152911.GA3011@sgi.com> (raw)
In-Reply-To: <CA+55aFw8bRwMRm8cWtTGRvd1AEP-LR7pYL-pEoBkHqJUuJrjSg@mail.gmail.com>

On Wed, Apr 10, 2013 at 08:10:05AM -0700, Linus Torvalds wrote:
> On Wed, Apr 10, 2013 at 4:16 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > I think rebooting on the same CPU where we booted up is something worth having in
> > general, as a firmware robustness feature. (assuming the CPU in question is still
> > online)
> 
> Yeah, we've had issues with ACPI in the past, so I do think we should
> always reboot using the BP. Even if it almost certainly works on 99+%
> of all machines on any random CPU.
> 
> The optimal solution would be to just speed up the
> disable_nonboot_cpus() code so much that it isn't an issue. That would
> be good for suspending too, although I guess suspend isn't a big issue
> if you have a thousand CPU's.
> 
> Has anybody checked whether we could do the cpu_down() on non-boot
> CPU's in parallel? Right now we serialize the thing completely, with
> one single
> 
>     for_each_online_cpu(cpu) {
>         ...
> 
> loop that does a synchrinous _cpu_down() for each CPU. No wonder it
> takes forever. We do __stop_machine() over and over and over again:
> the whole thing is basically O(n**2) in CPU's.

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.

Note that __cpu_notify() has to be called for all cpus being
shut down because the cpu_chain notifier call chain has cpu as a
parameter.  The delema is that cpu_chain notifiers need to be called on
all cpus, but cannot be done in parallel due to __cpu_notify() not being
thread safe.  Spinning through the notifier chain sequentially for all
cpus just takes a long time.

The real fix would be to make the &cpu_chain notifier per cpu, or at
least thread safe, so that all the cpus being shut down could do so
in parallel.  That is a significant change with ramifications on
other code.

I will post a patch shortly with the cpu bitmask change.  Changing
__cpu_notify() will take more discussion.

>                         Linus

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

  reply	other threads:[~2013-04-10 15:29 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 [this message]
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
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=20130410152911.GA3011@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.