From: Andrew Morton <akpm@linux-foundation.org>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: "Mike Frysinger" <vapier.adi@gmail.com>,
linux-kernel@vger.kernel.org, "Greg Ungerer" <gerg@snapgear.com>,
"Russell King" <rmk@arm.linux.org.uk>,
"Paul Mundt" <lethal@linux-sh.org>,
"Tim Bird" <tim.bird@am.sony.com>,
bryan.wu@analog.com
Subject: Re: early_printk accessing __log_buf
Date: Mon, 23 Jul 2007 15:34:37 -0700 [thread overview]
Message-ID: <20070723153437.4fc62253.akpm@linux-foundation.org> (raw)
In-Reply-To: <200707231815.38124.rgetz@blackfin.uclinux.org>
On Mon, 23 Jul 2007 18:15:37 -0400
Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Mon 23 Jul 2007 16:15, Andrew Morton pondered:
> > This code would be
> > simpler if it did not attempt to read more than one char at a time. It
> > will be plenty fast enough.
>
> When systems have NMI kick off due to power failure, and you want to grab the
> log buffer to write it to flash before power really dies - every cycle
> counts.
>
> A single function which does the copy as a loop (existing) is going to be much
> faster than the overhead of 1024 function calls to copy the last k.
I'd expect the overhead of the (fully-cached) instructions to be
insignificant compared to the time to write to flash?
> > The magical interpretation of len isn't very nice.
>
> There are lots of places in the kernel which have magic in them :)
Lots of the kernel is pretty crappy. One of our main tools for fixing that is to
ensure that new stuff is non-crappy.
next prev parent reply other threads:[~2007-07-23 22:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 21:56 early_printk accessing __log_buf Robin Getz
2007-07-18 22:16 ` Andrew Morton
2007-07-18 23:39 ` Robin Getz
2007-07-18 23:53 ` Mike Frysinger
2007-07-19 3:37 ` Robin Getz
2007-07-19 3:47 ` Andrew Morton
2007-07-19 0:26 ` Andrew Morton
2007-07-19 2:26 ` Stephane Couture
2007-07-19 3:58 ` Robin Getz
2007-07-22 23:50 ` Mike Frysinger
2007-07-23 0:14 ` Paul Mundt
2007-07-23 18:19 ` Robin Getz
2007-07-23 20:15 ` Andrew Morton
2007-07-23 20:54 ` Mike Frysinger
2007-07-23 21:05 ` Andrew Morton
2007-07-23 22:10 ` Mike Frysinger
2007-07-23 22:15 ` Robin Getz
2007-07-23 22:34 ` Andrew Morton [this message]
2007-07-24 17:50 ` Robin Getz
2007-07-24 18:12 ` Andrew Morton
2007-07-24 20:12 ` Robin Getz
2007-07-24 21:30 ` Andrew Morton
2007-07-31 7:47 ` Mike Frysinger
2007-07-31 7:59 ` Bryan Wu
2007-07-31 8:11 ` Mike Frysinger
2007-07-31 18:36 ` Andrew Morton
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=20070723153437.4fc62253.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bryan.wu@analog.com \
--cc=gerg@snapgear.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=rmk@arm.linux.org.uk \
--cc=tim.bird@am.sony.com \
--cc=vapier.adi@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