[lkml]   [2011]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/5] init: Shrink early messages to prevent overflowing the kernel log buffer

    v2: updated to apply to x86-tip

    On larger systems, information in the kernel log is lost because
    there is so much early text printed, that it overflows the static
    log buffer before the log_buf_len kernel parameter can be processed,
    and a bigger log buffer allocated.

    Distros are relunctant to increase memory usage by increasing the
    size of the static log buffer, so minimize the problem by allocating
    the new log buffer as early as possible, and reducing the amount
    of characters those early messages generate.

    Some stats from testing these changes on our current lab UV systems.
    (Both of these systems lost all of the e820 and EFI memmap ranges
    before the changes.)

    System X:
    8,793,945,145,344 bytes of system memory
    256 nodes
    599 EFI Mem ranges
    4096 cpu_ids
    43% of static log buffer unused

    System Y:
    11,779,115,188,224 bytes of system memory
    492 Nodes
    976 EFI Mem ranges
    1968 cpu_ids
    17% of static log buffer unused

    The last stat is how close the static log buffer came
    to overflowing. While these resources are fairly close
    to today's max limits, there is not a lot of head room
    for growth.

    An alternative for the future might be to create a larger
    static log buffer in the __initdata section, and then
    always allocate a dynamically sized log buffer to replace
    it. This would also allow shrinking the log buffer for
    memory tight situations. But it would add complexity to
    the code.


     \ /
      Last update: 2011-02-17 19:53    [W:0.018 / U:37.584 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site