linux-kernel - Re: New fast(?)-boot results on ARM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Aug 2009 20:57:31 +0200
From:	Robert Schwebel <r.schwebel@...gutronix.de>
To:	Zan Lynx <zlynx@....org>
Cc:	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Tim Bird <tim.bird@...sony.com>, kernel@...gutronix.de
Subject: Re: New fast(?)-boot results on ARM

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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/