lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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 :)



    \
     
     \ /
      Last update: 2009-11-02 15:17    [W:0.023 / U:32.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site