lkml.org 
[lkml]   [2011]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site