linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Schwebel <r.schwebel@pengutronix.de>
To: Zan Lynx <zlynx@acm.org>
Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
	Arjan van de Ven <arjan@linux.intel.com>,
	Tim Bird <tim.bird@am.sony.com>,
	kernel@pengutronix.de
Subject: Re: New fast(?)-boot results on ARM
Date: Fri, 14 Aug 2009 20:57:31 +0200	[thread overview]
Message-ID: <20090814185731.GN13320@pengutronix.de> (raw)
In-Reply-To: <4A85AAC4.7050505@acm.org>

Zan,

On Fri, Aug 14, 2009 at 12:19:48PM -0600, Zan Lynx wrote:
> > That's factor 70 away from the 110 ms boot time Tim has talked about
> > some days ago (and he measured on an ARM cpu which had almost half
> > the speed of this one), and I'm wondering what we can do to improve
> > the boot time.
>
> 2.4s in uncompression? That seems like an obvious target for
> improvement.

Indeed, we'll check that.

However, I have a little bit the impression that most systems which are
hyped as "fast boot" out there are optimized so aggressively that they
are not really usable in real life applications any more. So we try to
configure the systems in a "realistic" way. I know that we won't get the
last milliseconds that way - but I'd like to find out how far we can go.

> Your kernel seems awfully large. 3104K code? You should definitely find
> out what is making it that big and cut out everything you do not need.

Definitely, will audit again.

> You might even try some of the embedded system scripts that rip out
> all the printk strings.

Hmm, that's definitely in the "last-minute-before-product" category.

> If you get the kernel size way down then use a uncompressed kernel and
> it should boot a lot faster if the bottleneck is CPU speed.

I'll try that.

> However, it is probably IO speed. There could be something really wrong
> and slow with your MTD. Does it DMA or is it doing something crazy like
> using the CPU to read a byte at a time?

Will check.

> Or maybe its cheap and slow flash. In that case I think your only hope
> is to make all the code as small as possible and/or find a different
> flash filesystem that does not have to read so much of the device to
> mount. Perhaps use a read-only compressed filesystem for the system
> binaries and reflash it for software upgrades. Only init and mount the
> writable flash for user-storable data well after system boot has
> finished.

That would be also a last-minute change, but surely worth to be
evaluated.

We recently changed from jffs2 to ubifs and hoped to gain speed during
that step.

Thanks for your feedback!

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2009-08-14 18:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-14 17:02 New fast(?)-boot results on ARM Robert Schwebel
2009-08-14 18:19 ` Zan Lynx
2009-08-14 18:46   ` Jamie Lokier
2009-08-14 18:58     ` Robert Schwebel
2009-08-14 18:57   ` Robert Schwebel [this message]
2009-08-14 21:01     ` Linus Walleij
2009-08-14 21:15       ` Robert Schwebel
2009-08-14 21:35       ` Zan Lynx
2009-08-15  6:21         ` Artem Bityutskiy
2009-08-14 20:04 ` Denys Vlasenko
2009-08-14 20:43   ` Robert Schwebel
2009-08-15  5:59     ` Dirk Behme
2009-08-15 10:35     ` Johannes Stezenbach
2009-08-18 10:06       ` Marco Stornelli
2009-08-18 10:21         ` Robert Schwebel
2009-08-18 10:34           ` Alex Riesen
2009-08-18 10:44             ` Robert Schwebel
2009-08-18 10:48               ` Alex Riesen
2009-08-18 10:53                 ` Robert Schwebel
2009-09-04 16:16       ` Wolfram Sang
2009-09-09 14:33         ` Johannes Stezenbach
2009-09-10  0:03           ` Denys Vlasenko
2009-08-17 19:15     ` Tim Bird
2009-08-17 22:35       ` new ipdelay= option for faster netboot (was Re: New fast(?)-boot results on ARM) Tim Bird
2009-08-18  1:03         ` new ipdelay= option for faster netboot David Miller
2009-08-18  1:24           ` Tim Bird
2009-08-18  1:27             ` David Miller
2009-08-18  1:40               ` Tim Bird
2009-08-18  1:56                 ` David Miller
2009-08-19 11:57                 ` Jamie Lokier
2009-08-18  4:56               ` Denys Vlasenko
2009-08-18  5:00                 ` David Miller
2009-08-18  1:31           ` Rick Jones
2009-08-18  2:45             ` david
2009-08-18  4:56               ` Willy Tarreau
2009-08-15  6:14   ` New fast(?)-boot results on ARM Artem Bityutskiy
2009-08-18 14:06 ` Sascha Hauer
2009-08-18 15:31   ` Dirk Behme
2009-08-18 16:34     ` Marco Stornelli
2009-08-18 18:23     ` Tim Bird
2009-08-19  7:21     ` Sascha Hauer
2009-08-19 16:20       ` Dirk Behme
2009-08-20  8:57         ` Sascha Hauer

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=20090814185731.GN13320@pengutronix.de \
    --to=r.schwebel@pengutronix.de \
    --cc=arjan@linux.intel.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@am.sony.com \
    --cc=zlynx@acm.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).