From: Robin Holt <holt@sgi.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Robin Holt <holt@sgi.com>, Russ Anderson <rja@sgi.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"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 12:55:19 -0500 [thread overview]
Message-ID: <20130410175519.GG3658@sgi.com> (raw)
In-Reply-To: <20130410172236.GE21951@gmail.com>
On Wed, Apr 10, 2013 at 07:22:36PM +0200, Ingo Molnar wrote:
>
> * Robin Holt <holt@sgi.com> wrote:
>
> > 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?
> > >
> > > 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.
> >
> > What, exactly, are you proposing with the NMI profiling? [...]
>
> I'm proposing to make 'reboot' overhead profilable, via a debug hack:
>
> echo 1 > /proc/sys/kernel/magic_dont_fully_reboot_flag
>
> perf record reboot
>
> perf is using NMIs to profile - and since much of cpu_down() is with irqs
> disabled, NMI profiling would be needed to see inside the overhead.
>
> (Assuming the 240 msecs is CPU overhead, not waiting for some IRQ/IPI event.)
Let me give it a try.
Robin
next prev parent reply other threads:[~2013-04-10 17:55 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 [this message]
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=20130410175519.GG3658@sgi.com \
--to=holt@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rja@sgi.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.