svn commit: r304321 - in head/sys: boot/efi/boot1 boot/efi/loader boot/i386/boot2 boot/i386/gptboot boot/i386/gptzfsboot boot/i386/zfsboot boot/userboot/ficl boot/userboot/userboot boot/userboot/zf...

Slawa Olhovchenkov slw at zxy.spb.ru
Tue Aug 23 11:29:52 UTC 2016


On Tue, Aug 23, 2016 at 11:05:47AM +0300, Toomas Soome wrote:

> 
> > On 22. aug 2016, at 17:56, Toomas Soome <tsoome at me.com> wrote:
> > 
> > 
> >> On 22. aug 2016, at 17:19, Warner Losh <imp at bsdimp.com> wrote:
> >> 
> >> On Mon, Aug 22, 2016 at 3:44 AM, Toomas Soome <tsoome at me.com> wrote:
> >>> I do suspect the size difference there is partially due to ficl, in illumos (ficl 4):
> >>> 
> >>> -rw-r--r--   1 tsoome   staff     132508 aug 22 09:18 libficl.a
> >>> 
> >>> and freebsd (ficl 3):
> >>> 
> >>> -rw-r--r--  1 root  wheel  213748 Aug 19 01:57 libficl.a
> >>> 
> >>> so, there definitely is some space…
> >> 
> >> Same compiler? Clang bloats the boot code rather substantially, even after
> >> all the flags to tell it to generate smaller code are used. gcc 4.2.x
> >> built stuff
> >> was substantially smaller.
> >> 
> >> There's a 520kb limit enforced in the boot1 for similar reasons. Looks like
> >> the combination of options makes us use just enough extra memory to
> >> sink the battleship...
> >> 
> >> Warner
> >> 
> > 
> > 
> > Actually I only now realized I was comparing apples with oranges… I forgot the fbsd builds 32bit version in ficl32, this one is 64bit. and yes the 32bit version is not that big at all:D
> > 
> > Also, after done some digging, I have found few instances of duplicated code (we can share sha2 with geli and so if sha512 is already needed, it will become another “free lunch”). Also, unless I’m mistaken, for some reason the bzip *compression* is brought in - correct me if I’m wrong, but afaik only decompression is needed…
> > 
> > So before going after “useless features”, there are some “hidden” resources to remove extra fat.
> > 
> 
> I did some more digging. while ld has —gc-sections to clean up unused bits, to make it effective, the code build does also need -Os -fdata-sections -ffunction-sections.
> So I did just very simple test by adding those flags to bsd.stand.mk and:
> 
> first the “default” binaries from /boot:
> -r-xr-xr-x  1 root  wheel  446464 Aug 19 08:46 /boot/zfsloader
> -rw-r--r--  1 root  wheel  438272 Aug 23 00:30 /boot/zfsloader.b
> -r-xr-xr-x  1 root  wheel  446464 Aug  5 08:37 /boot/zfsloader.old
> -r--r--r--  1 root  wheel  406568 Aug 19 08:46 /boot/userboot.so
> 
> (note, zfsloader.b here is built with https://reviews.freebsd.org/D7600)
> 
> now after adding compile flags  -Os -fdata-sections -ffunction-sections:
> 
> -rw-r--r--  1 root  wheel  389120 Aug 23 10:12 zfsloader
> -rwxr-xr-x  1 root  wheel  378156 Aug 23 10:12 zfsloader.bin
> -rwxr-xr-x  1 root  wheel  437514 Aug 23 10:12 zfsloader.sym
> -rwxr-xr-x  1 root  wheel  375912 Aug 23 10:03 userboot.so
> 
> and finally test for Andriy with:
> LOADER_BZIP2_SUPPORT=yes
> LOADER_FIREWIRE_SUPPORT=yes
> 
> -rw-r--r--  1 root  wheel  421888 Aug 23 10:22 zfsloader
> -rwxr-xr-x  1 root  wheel  409932 Aug 23 10:22 zfsloader.bin
> -rwxr-xr-x  1 root  wheel  472021 Aug 23 10:22 zfsloader.sym
> -rwxr-xr-x  1 root  wheel  375912 Aug 23 10:22 userboot.so
> 
> note the userboot.so did not change from those flags.
> 
> This is just an result from compile, and by adding 3 options to bsd.stand.mk; however, not all Makefiles in loader tree seem to include it, and most importantly, haven’t tested real boot yet;)
> 
> To conclude, some more work is needed to review the Makefiles, build options used etc, also I don’t know all the background why the compiler options are set as they currently are - were there any related compiler/linker bugs, or any other reasons, also how/if other platforms are affected - for example bsd.stand.mk does set -Os for pc98, but not for others…

This is only size on disk, memory consuming still same, IMHO.


More information about the svn-src-head mailing list