Date: Tue, 23 Aug 2016 15:00:32 +0300 From: Toomas Soome <tsoome@me.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Warner Losh <imp@bsdimp.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>, Toomas Soome <tsoome@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: 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... Message-ID: <C8A2C3A1-C35A-4993-AC0F-66F6B0AD51A6@me.com> In-Reply-To: <20160823112940.GW22212@zxy.spb.ru> References: <201608180037.u7I0b77A095653@repo.freebsd.org> <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> <AE24A37C-51F5-4CEC-9399-D7FDEBC93972@me.com> <CANCZdfo0P7CPPf4khzj_JnSjWQ4gVqK9wSEqW=LCdZKQwGh6Sw@mail.gmail.com> <AE896F50-D053-4C30-BB43-286E1CCDE4B8@me.com> <1C479C8A-9F58-425C-8AC2-0A6809F39ACA@me.com> <20160823112940.GW22212@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23. aug 2016, at 14:29, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: >=20 > On Tue, Aug 23, 2016 at 11:05:47AM +0300, Toomas Soome wrote: >=20 >>=20 >>> On 22. aug 2016, at 17:56, Toomas Soome <tsoome@me.com> wrote: >>>=20 >>>=20 >>>> On 22. aug 2016, at 17:19, Warner Losh <imp@bsdimp.com> wrote: >>>>=20 >>>> On Mon, Aug 22, 2016 at 3:44 AM, Toomas Soome <tsoome@me.com> = wrote: >>>>> I do suspect the size difference there is partially due to ficl, = in illumos (ficl 4): >>>>>=20 >>>>> -rw-r--r-- 1 tsoome staff 132508 aug 22 09:18 libficl.a >>>>>=20 >>>>> and freebsd (ficl 3): >>>>>=20 >>>>> -rw-r--r-- 1 root wheel 213748 Aug 19 01:57 libficl.a >>>>>=20 >>>>> so, there definitely is some space=E2=80=A6 >>>>=20 >>>> 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. >>>>=20 >>>> 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... >>>>=20 >>>> Warner >>>>=20 >>>=20 >>>=20 >>> Actually I only now realized I was comparing apples with oranges=E2=80= =A6 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 >>>=20 >>> 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 =E2=80=9Cfree lunch=E2=80=9D). Also, = unless I=E2=80=99m mistaken, for some reason the bzip *compression* is = brought in - correct me if I=E2=80=99m wrong, but afaik only = decompression is needed=E2=80=A6 >>>=20 >>> So before going after =E2=80=9Cuseless features=E2=80=9D, there are = some =E2=80=9Chidden=E2=80=9D resources to remove extra fat. >>>=20 >>=20 >> I did some more digging. while ld has =E2=80=94gc-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: >>=20 >> first the =E2=80=9Cdefault=E2=80=9D 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 >>=20 >> (note, zfsloader.b here is built with = https://reviews.freebsd.org/D7600) >>=20 >> now after adding compile flags -Os -fdata-sections = -ffunction-sections: >>=20 >> -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 >>=20 >> and finally test for Andriy with: >> LOADER_BZIP2_SUPPORT=3Dyes >> LOADER_FIREWIRE_SUPPORT=3Dyes >>=20 >> -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 >>=20 >> note the userboot.so did not change from those flags. >>=20 >> 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=E2=80=99t tested real boot yet;) >>=20 >> To conclude, some more work is needed to review the Makefiles, build = options used etc, also I don=E2=80=99t 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=E2=80=A6 >=20 > This is only size on disk, memory consuming still same, IMHO. Actually this reduction above is entirely due to -Os, the =E2=80=94gc-sect= ions is not passed to linker (at least for zfsloader case). I think we = will need linker script to preserve set_Xcommand_set linker set to use = =E2=80=94gc-sections with ld. Loader heap is separate already and does not contribute to this issue. = Also, I already did test the boot with thinned zfsloader, both with and = without bzip2 are appearing to work, at least for this quick test = anyhow. rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C8A2C3A1-C35A-4993-AC0F-66F6B0AD51A6>