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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
