On Tue, Aug 23, 2016 at 03:00:32PM +0300, Toomas Soome wrote: > > > On 23. aug 2016, at 14:29, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: > > > > On Tue, Aug 23, 2016 at 11:05:47AM +0300, Toomas Soome wrote: > > > >> > >>> On 22. aug 2016, at 17:56, Toomas Soome <tso...@me.com> wrote: > >>> > >>> > >>>> On 22. aug 2016, at 17:19, Warner Losh <i...@bsdimp.com> wrote: > >>>> > >>>> On Mon, Aug 22, 2016 at 3:44 AM, Toomas Soome <tso...@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. > > Actually this reduction above is entirely due to -Os, the —gc-sections 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 —gc-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.
Main trouble (by kib@) is 640KB real mode limit. Separated heap don't soled this. May be solution is early switch to protected mode, boot2? _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
