linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Mike Travis <travis@sgi.com>
Cc: David Rientjes <rientjes@google.com>,
	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, Tejun Heo <tj@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH 1/4] printk: Allocate kernel log buffer earlier
Date: Sun, 27 Feb 2011 13:09:49 +0100	[thread overview]
Message-ID: <20110227120949.GF16453@elte.hu> (raw)
In-Reply-To: <20110225180634.017570095@gulag1.americas.sgi.com>


* Mike Travis <travis@sgi.com> wrote:

> On larger systems, because of the numerous ACPI, Bootmem and EFI
> messages, the static log buffer overflows before the larger one
> specified by the log_buf_len param is allocated.  Minimize the
> potential for overflow by allocating the new log buffer as soon
> as possible.
> 
> We do this by changing the log_buf_len from an early_param to a
> _setup param.  But _setup params are processed before the
> alloc_bootmem is available, so this function will now just save
> the requested log buf len.  The real work routine (setup_log_buf)
> is called after bootmem is available.
> 
> Signed-off-by: Mike Travis <travis@sgi.com>
> Reviewed-by: Jack Steiner <steiner@sgi.com>
> Reviewed-by: Robin Holt <holt@sgi.com>
> ---
>  arch/x86/kernel/setup.c |    5 +++
>  include/linux/printk.h  |    4 ++
>  init/main.c             |    1 
>  kernel/printk.c         |   75 ++++++++++++++++++++++++++++--------------------
>  4 files changed, 54 insertions(+), 31 deletions(-)

Well, the modern allocation method is memblock - available on all major 
architectures.

You could avoid all this ugly workaround of bootmem limitations by moving the 
allocation to memblock_alloc() and desupporting the log_buf_len= boot parameter
on non-memblock architectures.

kernel log buffer size can be configured via the .config so they will not be left 
without larger buffers.

Doing this should also have the advantage of getting all the early x86 messages into 
the larger buffer already, reducing the pressure to apply some of the other patches 
in your series.

Thanks,

	Ingo

  reply	other threads:[~2011-02-27 12:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-25 18:06 [PATCH 0/4] init: Shrink early messages to prevent overflowing the kernel log buffer Mike Travis
2011-02-25 18:06 ` [PATCH 1/4] printk: Allocate kernel log buffer earlier Mike Travis
2011-02-27 12:09   ` Ingo Molnar [this message]
2011-02-27 12:15     ` Ingo Molnar
2011-02-28  1:34       ` Yinghai Lu
2011-02-28  8:01         ` Ingo Molnar
2011-02-28 19:26           ` Mike Travis
2011-03-01  7:35             ` Ingo Molnar
2011-02-28  8:06         ` Ingo Molnar
2011-02-28 19:18           ` Yinghai Lu
2011-02-28 19:29           ` Mike Travis
2011-02-28 19:23         ` Mike Travis
2011-02-28 19:46           ` Yinghai Lu
2011-02-28 20:02             ` Mike Travis
2011-02-28 22:59               ` Yinghai Lu
2011-03-31  0:41                 ` [PATCH 1/2] memblock: add error return when CONFIG_HAVE_MEMBLOCK is not set Mike Travis
2011-03-31  1:40                   ` Yinghai Lu
2011-03-31 15:23                     ` Mike Travis
2011-03-31 16:17                       ` Yinghai Lu
2011-04-07 19:43                   ` Mike Travis
2011-04-08  6:40                     ` Ingo Molnar
2011-03-01  7:42           ` [PATCH 1/4] printk: Allocate kernel log buffer earlier Ingo Molnar
2011-02-28 19:14     ` Mike Travis
2011-02-25 18:06 ` [PATCH 2/4] printk: Break out printk_time Mike Travis
2011-02-27 11:56   ` Ingo Molnar
2011-02-25 18:06 ` [PATCH 3/4] printk: Minimize time zero output Mike Travis
2011-02-25 18:06 ` [PATCH 4/4] x86: Minimize SRAT messages Mike Travis
2011-02-27 12:03   ` Ingo Molnar
2011-02-28 19:41     ` Mike Travis
2011-03-01  7:51       ` Ingo Molnar
2011-03-31  2:38         ` Len Brown
2011-03-31  4:40           ` Yinghai Lu

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=20110227120949.GF16453@elte.hu \
    --to=mingo@elte.hu \
    --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=rientjes@google.com \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=travis@sgi.com \
    --cc=x86@kernel.org \
    --cc=yhlu.kernel@gmail.com \
    --cc=yinghai@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).