RFC: Hiding per-CPU kernel output behind bootverbose

[Stefan Blachmann]

I would also like a solution to this issue, which is looking highly
unprofessional and uselessly wasting space in the dmesg ring buffer.

In the first version of my sysutils/cpupdate tool I also had spammy
output like being complained about.
This was hard-to-read. Thus I changed code so that identical cores
output was collected up in blocks of single output, i.e.: "core #n to
#m: <identical stats>".
If all cpus are identical, cpu stats will be output only once this
way, else in subsequent blocks comprising all identical cores on
different cpus.

To avoid the spamming at bootup and microcode updating, the kernel
would need such a function to read/evaluate *all* cores in a row, like
I did in cpupdate.
This would be only a few lines of code.


On 4/19/18, Konstantin Belousov <kib at freebsd.org> wrote:
> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>