RFC: Hiding per-CPU kernel output behind bootverbose

[Conrad Meyer]

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?

Best,
Conrad