Date: Sat, 21 Apr 2018 07:55:00 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Stefan Blachmann <sblachmann@gmail.com> Cc: Konstantin Belousov <kib@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Colin Percival <cperciva@tarsnap.com>, Conrad Meyer <cem@freebsd.org> Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <201804211455.w3LEt0sa076406@slippy.cwsent.com> In-Reply-To: Message from Stefan Blachmann <sblachmann@gmail.com> of "Fri, 20 Apr 2018 01:05:00 %2B0200." <CACc-My0qnG1f7Szxho-6rcGfTbeEg_dnpe5VtunL8TAuyVtppA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CACc-My0qnG1f7Szxho-6rcGfTbeEg_dnpe5VtunL8TAuyVtppA@mail.gma il.com> , Stefan Blachmann writes: > I would also like a solution to this issue, which is looking highly > unprofessional and uselessly wasting space in the dmesg ring buffer. Really? Have you looked at Red Hat (or Oracle) Linux or Solaris dmesg output? Why neuter 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. Maybe the solution is a Red Hat style of slider bar or a Windows style graphic to hide messages. Personally, a Red Hat style of slider might work. Hit the enter to see the gory details. Hit enter again to see the slider bar again. It doesn't have to be a slider -- we don't want to look like a RH derivative. It can be any kind of progress indicator. Additionally, green and red checkboxes like HP/UX and Red Hat (they ripped that off from HP) is okay but when something fails you're in the dark. (At $JOB we use HP SA, with its green checkmarks and red x's on various dashboard style outputs. All you can tell is something is out of compliance but not where the actual problem is. This is totally unacceptable.) ~cy > > > 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" > > > _______________________________________________ > 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" > -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201804211455.w3LEt0sa076406>