RFC: Hiding per-CPU kernel output behind bootverbose

[Konstantin Belousov]

On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote:
> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote:
> >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs)
> >> the boot time console output contains a large number of lines of the forms
> >>
> >> SMP: AP CPU #N Launched!
> >> cpuN: <ACPI CPU> on acpi0
> >> estN: <Enhanced SpeedStep Frequency Control> on cpuN
> >>
> >> Having 128 almost-identical lines of output doesn't seem very useful, and
> >> it actually has a nontrivial impact on the time spent booting.
> >>
> >> Does anyone mind if I hide these by default, having them only show up if
> >> boot verbosity is requested?
> 
> +1.  For the device attaches, perhaps it makes sense to add a device
> 'spammy' flag, and set it for per-CPU devices like cpuN or estN.  Then
> the generic attach code can choose whether to print spammy attaches
> based on bootverbose.  dmesg for device attaches seems mostly
> redundant with devinfo(8) for persistent devices like ACPI CPU and
> est(4).
> 
> > The 'CPU XX Launched' messages are very useful for initial diagnostic
> > of the SMP startup failures. You need to enable bootverbose to see the
> > hang details, but for initial hint they are required. Unfortunately, AP
> > startup hangs occur too often to pretend that this can be delegated to
> > very specific circumstances.
> 
> Really?  I don't know that I've ever seen an AP startup hang.  How
> often do they occur?

It was epidemic with Sandy Bridge, mostly correlated to specific BIOS
supplier and its interaction with the x2APIC enablement, see madt.c:170
and below.

There were several recent reports of the issue with Broadwell Xeon
machines, no additional data or resolution.

There are sporadic reports of the problem, where I do not see
a clear commonality.