From: Zan Lynx <zlynx@acm.org>
To: Robert Schwebel <r.schwebel@pengutronix.de>
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 12:19:48 -0600 [thread overview]
Message-ID: <4A85AAC4.7050505@acm.org> (raw)
In-Reply-To: <20090814170228.GM13320@pengutronix.de>
Robert Schwebel wrote:
> - 2.4 s up from u-boot to the end of "Uncompressing Linux"
> - 300 ms until ubifs initialization starts
> - 3.7 s for ubifs, until "mounted root"
>
> So we basically have 7 s for the kernel. The rest is userspace, which hasn't
> seen much optimization yet, other than trying to start the GUI application as
> early as possible, while doing all other init stuff in parallel. Adding "quiet"
> brings us another 300 ms.
>
> 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.
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.
You might even try some of the embedded system scripts that rip out all
the printk strings.
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.
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?
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.
--
Zan Lynx
zlynx@acm.org
"Knowledge is Power. Power Corrupts. Study Hard. Be Evil."
next prev parent reply other threads:[~2009-08-14 18:19 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 [this message]
2009-08-14 18:46 ` Jamie Lokier
2009-08-14 18:58 ` Robert Schwebel
2009-08-14 18:57 ` Robert Schwebel
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=4A85AAC4.7050505@acm.org \
--to=zlynx@acm.org \
--cc=arjan@linux.intel.com \
--cc=kernel@pengutronix.de \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
--cc=tim.bird@am.sony.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;
as well as URLs for NNTP newsgroup(s).