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]

Message-ID: <20090814211500.GC31727@pengutronix.de>
Date:	Fri, 14 Aug 2009 23:15:00 +0200
From:	Robert Schwebel <r.schwebel@...gutronix.de>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Zan Lynx <zlynx@....org>, 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

On Fri, Aug 14, 2009 at 11:01:58PM +0200, Linus Walleij 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.
> 
> We got rid of uncompression on a flash-based system vastly improving
> boot time. The reason is that compressed kernels are faster only when
> the throughput to the persistent storage is lower than the decompression
> throughput, and on typical embedded systems with DMA the throughput to
> memory outperforms the CPU-based decompression.
> 
> Of course it depends on a lot of stuff like performance of flash controller,
> kernel storage filesystem performance, DMA controller performance,
> cache architecture etc so it's individual per-system.

We have also done that on NOR based systems, but I'm not sure if it will
work out for NAND as well.

Thanks,

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/