Date: Fri, 20 Apr 2018 01:05:00 +0200 From: Stefan Blachmann <sblachmann@gmail.com> To: Konstantin Belousov <kib@freebsd.org> Cc: Conrad Meyer <cem@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Colin Percival <cperciva@tarsnap.com> Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <CACc-My0qnG1f7Szxho-6rcGfTbeEg_dnpe5VtunL8TAuyVtppA@mail.gmail.com> In-Reply-To: <20180419214550.GF6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <CAG6CVpUerOo%2B55nJq61Hy83RYpbOZS6puEDuemspfNS12urZZw@mail.gmail.com> <20180419214550.GF6887@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACc-My0qnG1f7Szxho-6rcGfTbeEg_dnpe5VtunL8TAuyVtppA>