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: <4A8653DC.3050102@gmail.com>
Date:	Sat, 15 Aug 2009 09:21:16 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Zan Lynx <zlynx@....org>
CC:	Linus Walleij <linus.ml.walleij@...il.com>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	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 08/15/2009 12:35 AM, Zan Lynx wrote:
> Linus Walleij wrote:
>> 2009/8/14 Robert Schwebel <r.schwebel@...gutronix.de>:
>>> 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.
>>
>> 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.
>
> I thought of another thing to check related to slow decompression. If
> the kernel, bootloader or hardware is in charge of setting CPU power and
> speed scaling, then you should check that it boots with the CPU set at
> maximum speed instead of slowest.

zlib is slow on decompression, and lzo is much faster. So if you implement
lzo compression, you'll probably speed things up a little as well. I saw
some discussions about this on lkml. Having no compression at all may also
be a good thing to try.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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/