mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jack Steiner <steiner@sgi.com>, Robin Holt <holt@sgi.com>,
	Len Brown <len.brown@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	linux-acpi@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/6] init: Shrink early messages to prevent overflowing the kernel log buffer
Date: Fri, 18 Feb 2011 20:47:05 -0600	[thread overview]
Message-ID: <20110219024705.308511527@gulag1.americas.sgi.com> (raw)


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.

-- 

             reply	other threads:[~2011-02-19  2:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-19  2:47 Mike Travis [this message]
2011-02-19  2:47 ` [PATCH 1/6] ACPI: Minimize X2APIC initial messages Mike Travis
2011-02-20  1:50   ` David Rientjes
2011-02-21 20:42     ` Mike Travis
2011-02-22  0:13       ` David Rientjes
2011-02-19  2:47 ` [PATCH 2/6] x86: Minimize initial e820 messages Mike Travis
2011-02-20  1:51   ` David Rientjes
2011-02-21 20:50     ` Mike Travis
2011-02-22  0:13       ` David Rientjes
2011-02-22 18:43   ` Bjorn Helgaas
2011-02-19  2:47 ` [PATCH 3/6] x86: Minimize SRAT messages Mike Travis
2011-02-20  1:51   ` David Rientjes
2011-02-23 21:24     ` Mike Travis
2011-02-24  4:12       ` David Rientjes
2011-02-19  2:47 ` [PATCH 4/6] printk: Break out printk_time Mike Travis
2011-02-20  1:51   ` David Rientjes
2011-02-19  2:47 ` [PATCH 5/6] printk: Minimize time zero output Mike Travis
2011-02-20  1:51   ` David Rientjes
2011-02-21 20:56     ` Mike Travis
2011-02-22  0:13       ` David Rientjes
2011-02-19  2:47 ` [PATCH 6/6] printk: Allocate kernel log buffer earlier Mike Travis
  -- strict thread matches above, loose matches on Subject: below --
2011-01-21 20:25 [PATCH 0/6] init: Shrink early messages to prevent overflowing the kernel log buffer Mike Travis
2011-01-19 23:01 Mike Travis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110219024705.308511527@gulag1.americas.sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=holt@sgi.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yhlu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®