mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] making the printk buffer bigger
Date: Tue, 30 Oct 2001 10:19:01 -0800	[thread overview]
Message-ID: <3709761319.1004437141@mbligh.des.sequent.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1011030135941.6694E-100000@delta.ds2.pg.gda.pl>

>> OK, seeing as people don't seem to want a decent size buffer on 
>> CONFIG_SMP machines, could we at least do it under
>> CONFIG_MULTIQUAD? Loosing half my boot time messages is 
>> annoying, and I have gigabytes of RAM to waste. Please .......
> 
>  Hmm, and what exactly does prevent you from applying the patch privately
> for the time you are needing it for developent?

I don't just want it for development, I believe in capturing my boot messages 
all the time. If they're not visible, why bother printing them?

Why not just keep it as a patch? Partly the fact that it's a pain in the butt, 
and I keep forgetting to do it. In principle I think the default buffer ought 
to big enough to cope with the boot messages we put out. There's more 
messages on larger systems, hence it makes sense to have a larger buffer. 
Switching on CONFIG_SMP or CONFIG_MULTIQUAD is a crude 
approximation to estimating the size of boot messages. 

The correct solution is probably to either size it dynamically, or have a
seperate boot time buffer that we throw away afterwards. But for the 
sake of another 48Kb on machines with 2 - 16Gb of RAM, it's not worth
coding it, testing it, and risking the change.

M.

PS. Alan's solution was to turn off half the garbage that gets printed on
boot, which would work too. Especially half the stuff from the mps tables,
which we throw in the bin 2 nanoseconds after printing it. We could
turn off APIC_DEBUG by default, which would kill all the Dprintk's as
far as I can see ....




  reply	other threads:[~2001-10-30 18:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-22 23:24 Martin J. Bligh
2001-10-30  0:25 ` Martin J. Bligh
2001-10-30 13:14   ` Maciej W. Rozycki
2001-10-30 18:19     ` Martin J. Bligh [this message]
2001-10-31 11:31       ` Maciej W. Rozycki
2001-10-31 17:03         ` Martin J. Bligh

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=3709761319.1004437141@mbligh.des.sequent.com \
    --to=martin.bligh@us.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=torvalds@transmeta.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®