From: Ingo Molnar <mingo@elte.hu>
To: Mike Travis <travis@sgi.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
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>
Subject: Re: [PATCH 1/4] printk: Allocate kernel log buffer earlier
Date: Tue, 1 Mar 2011 08:42:39 +0100 [thread overview]
Message-ID: <20110301074239.GB12384@elte.hu> (raw)
In-Reply-To: <4D6BF63D.2020404@sgi.com>
* Mike Travis <travis@sgi.com> wrote:
> Yinghai Lu wrote:
> > please check updated patch...
> >
> > with the memblock change, you don't need to change acpi SRAT handling etc any
> > more.
>
> I had to debug a weird ACPI -> Node mapping last week and the
> "improved" SRAT messages helped that considerably. It was
> far easier to spot which Node didn't have the correct assignments.
> I'd submit that patch even without needing fewer (like 512 lines
> max instead of 4096 lines max) bytes in the log buffer.
I agree that better compressed output generally makes sense - you just need to solve
the ugliness aspect of it. (or get Len's Acked-by to add that code to drivers/acpi/)
Nevertheless doing this via memblock is obviously more important, as it solves the
early printk log overrun problem once and for all.
> Let's move on to far more important problems.
That's not the threshold for upstream inclusion though. (at least for patches that
we process via the -tip tree)
If you add crap to a single hardware driver then only that hardware is affected, but
if you change the way the printk buffer is allocated it is *very important*, because
like every single kernel message is affected by it.
So we scale up our review threshold with the importance of the piece of code
affected.
Thanks,
Ingo
next prev parent reply other threads:[~2011-03-01 7:43 UTC|newest]
Thread overview: 35+ 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
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 0:57 ` [PATCH 2/2] printk: Allocate kernel log buffer earlier v2 Mike Travis
2011-03-31 6:48 ` Ingo Molnar
2011-03-31 15:37 ` Mike Travis
2011-03-31 1:40 ` [PATCH 1/2] memblock: add error return when CONFIG_HAVE_MEMBLOCK is not set 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 ` Ingo Molnar [this message]
2011-02-28 19:14 ` [PATCH 1/4] printk: Allocate kernel log buffer earlier 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=20110301074239.GB12384@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
all inboxes | Powered by JetHome®