Messages in this thread | | | Date | Mon, 2 Nov 2009 15:15:15 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 1/8] SGI x86_64 UV: Add limit console output function |
| |
On Mon, Oct 26, 2009 at 10:55:31AM -0700, Mike Travis wrote: > > > Frederic Weisbecker wrote: >> On Fri, Oct 23, 2009 at 06:37:44PM -0500, Mike Travis wrote: >>> With a large number of processors in a system there is an excessive amount >>> of messages sent to the system console. It's estimated that with 4096 >>> processors in a system, and the console baudrate set to 56K, the startup >>> messages will take about 84 minutes to clear the serial port. >>> >>> This patch adds (for SGI UV only) a kernel start option "limit_console_ >>> output" (or 'lco' for short), which when set provides the ability to >>> temporarily reduce the console loglevel during system startup. This allows >>> informative messages to still be seen on the console without producing >>> excessive amounts of repetious messages. >>> >>> Note that all the messages are still available in the kernel log buffer. >> >> >> >> Well, this problem does not only concerns SGI UV but all boxes with a large >> number of cpus. >> >> Also, instead of adding the same conditionals in multiple places to solve >> the same problem (and that may even expand if we go further the SGI UV case, >> for example with other archs cpu up/down events), may be can you centralize, >> institutionalize this issue by using the existing printk mechanisms. >> >> I mean, may be that could be addressed by adding a new printk >> level flag, and then associate the desired filters against it. >> >> KERN_CPU could be a name, since this is targetting cpu events. >> > > I did try out something like this but the changes quickly became very intrusive, > and I was hoping for a "lighter" touch. The other potential fallout of adding > another printk level might affect user programs that sift through the dmesg > log for "interesting" info. > > Also, I could use some other config option to enable this, it's just that the > existing X86_UV was too convenient. ;-) I believe most systems would want this > turned off so the code size shrinks. And until you get the number of cpus into > the hundreds and thousands, the messages usually just fly by - particularly if > you're on a desktop system which has almost an infinite baud rate to the screen, > and usually hides the messages behind a splash screen anyways.
Ok :)
| |