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.DEB.1.10.0812261422010.10983@asgard.lang.hm>
Date:	Fri, 26 Dec 2008 14:28:03 -0800 (PST)
From:	david@...g.hm
To:	Jan Engelhardt <jengelh@...ozas.de>
cc:	Roland <devzero@....de>, linux-kernel@...r.kernel.org,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH] Compress kernel modules on installation

On Fri, 26 Dec 2008, Jan Engelhardt wrote:

> On Friday 2008-12-26 23:02, 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, from the graph you posted going to 6 or 7 would be 
a fairly significant win (final size to final size) without eathing _that_ 
much more cpu.

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.

>> however, I do need to ask what the sizes of the resulting files end up being
>> (on my system the last kernel that used modules was 2.4.31, so I can't just
>> look this up myself). in most cases disks are formatted with 4K blocks, so
>> unless it shrinks across such a boundry it's not actually going to help much.
>
> Hey, don't forget exotic filesystems that pack that together anyway.
> And if I fired up du right, then...
>
> $ 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

>> one other thing to consider would be some ability to load the
>> module out of a tar or cpio bundle, that way you end up saving all
>> the partial blocks from each module as well.
>
> tarfs, it's somewhere around the corner on the fuse pages probably.

watch out for a deadlock here. the more external tools that you need to 
get at the kernel modules, the more likely it is that one of those tools 
will need something that you can't get to without the modules loaded.

David Lang

--
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/