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

rgds,
toomas

_______________________________________________
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"

Reply via email to