linux-kernel - Re: [PATCH] Compress kernel modules on installation

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: <alpine.LSU.2.00.0812270014500.12031@fbirervta.pbzchgretzou.qr>
Date:	Sat, 27 Dec 2008 00:23:24 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	david@...g.hm
cc:	Roland <devzero@....de>, linux-kernel@...r.kernel.org,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH] Compress kernel modules on installation


On Friday 2008-12-26 23:28, david@...g.hm wrote:
>>>> ( see
>>>> http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/080/8051/8051f1.png
>>>> )
>>>
>>> this varies a lot on the particulars of the data being compressed.
>>
>> see my other reply.
>
> IIRC the default is 5

default is 6 (man gzip).

> instead of doing the compression when doing the modules_install do it when they
> are compiled (just like we do for the kernel itself). if you just spent the cpu
> to build the thing, the cpu to compress it isn't much.

I'd rather do the compression later on - or do you want
to spend gzipping all day when doing `make foo.ko`
as a developer? ;-)

>> $ find . -iname "*.gz" | xargs du -cs -B 4096 | grep total
>> 7086    total
>> $ echo $[7086*4096]
>> 29024256
>> $ echo $[29024256-24782942]
>> 4241314
>>
>> So that's like 4M going off for the block stuff. Given that
>> the compression actually saved about 50 MB, I think we
>> can live with the 4M - especially since they have been
>> there already one way or another.
>
> if I'm reading the numbers correctly that's about 16% of the space taken by the
> final result

Assuming that the x in (filesize % 4096 == x) is randomly distributed
over 0..4095 for gzip modules, I proclaim that it is similarly
randomly distributed for noncompressed modules. As such, the overhead
is always there and gzipping does not make it worse or better.
So you always have the overhead.

uncompressed:
$ du as above
113360896
$ byte counted:
109270606

differnece: 4.09 MB

You always pay that price for having single files.
So I dismiss it from the discussion ;-)
--
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/