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>] [day] [month] [year] [list]
Date:	Tue, 25 Nov 2008 10:45:30 +0100
From:	"Frans Meulenbroeks" <fransmeulenbroeks@...il.com>
To:	linux-kernel@...r.kernel.org, dwmw2@...radead.org, rob@...dley.ne
Subject: Re: [PATCH] create option to compress initramfs within the kernel

Dang. Did a reply instead of a reply all. Here it is again now also to
lkml and dwmw2.

2008/11/23 Rob Landley <rob@...dley.net>:

>> Rationale is that if you create a compressed kernel image (e.g. by
>> make bzImage) it is not very efficient and useful to compress initramfs
>> as the initramfs will be compressed anyway when the kernel image is
>> compressed.
>
> Actually it saves intermediate space (the cpio archive and the decompressed
> ramfs coexist during the decompression, until the kernel can free the cpio
> archive), so it does serve a purpose.  (Given cache effects leaving it
> compressed may actually wind up being faster on modern CPUs because it dirties
> fewer pages.)
>
> It also eats CPU, which is at more of a premium than memory on some little
> battery powered wind-up boxes.  But I'd be happier seeing some actual
> benchmark numbers on a device that would actually _notice_ this change.

I agree that a compressed initramfs image saves intermediate RAM
space. If one cannot afford to use this temporary space, then a
compressed initramfs is definitely better.
Double compression definitely eats CPU. I did not bench the
compression part alone.but I'll try to find some time to bench it in
more detail. Of course it also depends on the size of the initramfs.
For a 300k initramfs this is not going to make much of a difference.
However we once turned our 20MB or so squashfs image into initramfs
and it took about 1.5 seconds to decompress and populate the buffer
cache. (20MB is compressed, uncomressed it is around 50M) (I do not
have exact figures handy, but this is what I recall). CPU is a 180 Mhz
or so MIPS.

>
>> @@ -257,6 +258,9 @@ while [ $# -gt 0 ]; do
>>                       default_list="$arg"
>>                       ${dep_list}default_initramfs
>>                       ;;
>> +             "-c")   # compress
>> +                     compress=1
>> +                     ;;
>
> You're changing the default behavior for people who run this script directly.
> Just FYI.

Do they exist? Actually I went for -c because it is mnemonically easy
to say that c is for compress. If there are better suggestions for an
option that does not compress,. I am more than happy to change things.
(I don't really like things like -n for nocompress).;

>
>> --- a/usr/Kconfig
>> +++ b/usr/Kconfig
>> @@ -44,3 +44,14 @@ config INITRAMFS_ROOT_GID
>>         owned by group root in the initial ramdisk image.
>>
>>         If you are not sure, leave it set to "0".
>> +
>> +config INITRAMFS_COMPRESS
>> +     bool "Compress initramfs image"
>> +     default y
>> +     help
>> +       If you want a compressed initramfs image in your kernel say y
>> +       If you do not want your initramfs image to be compressed say n.
>> +       A compressed initramfs is generally not useful if you also have a
>> +       compressed kernel (vmlinuz, bzImage).
>
> This should probably be in the CONFIG_EMBEDDED menu.

Can be done, but to me it felt it would be better to keep things
together, hence I added to usr/Kconfig.
Is there a policy on this? David, as embedded maintainer, do you have
an opinion?

Thanks for your feedback! Frans.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ