Re: [PATCH 1/8] SGI x86_64 UV: Add limit console output function

From: Frederic Weisbecker
Date: Mon Nov 02 2009 - 09:15:36 EST

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 :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at