From owner-svn-src-head@freebsd.org Tue Aug 23 12:26:15 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC604BC31BA; Tue, 23 Aug 2016 12:26:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E00819E4; Tue, 23 Aug 2016 12:26:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OCD000003OPX100@st13p35im-asmtp001.me.com>; Tue, 23 Aug 2016 12:26:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1471955169; bh=j6FqPoVi04MO95ghKGnvLPxJW0UWVc8iJklvJ3l1zCM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=rMZYisDx8w7ztNojjQlKdLaAn0ao5FyJle7KXNDw3fhcWz9MObPVozSqskFKQySjm pVjsW9hNzI7vYur8lbQa1PPFxl1qF8Sj3nvzFH7ayJqNvt48ThO+VGqvo9sYw/jRdK czOkNCLgH6DPwWwqzV5i0NxYKSyWPl2K9ZhDb6Ro++Guc2fVaBVsmz8jy7/kdCS/5M fzmZIPD6+mj8Hr6sq6jYbaUG7AHssfiGKNH1lQFaYhvLfqPcbeimT+yZGVvi6ilQ0L KWGj3VOsZa0LuBASJ/FxCcyqUUsNmX/MmffSfx9A040VdxpwS4zzNVbM93byk3cu23 0VC99pRZ6B55Q== Received: from [88.196.10.91] (91-10-196-88.dyn.estpak.ee [88.196.10.91]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OCD005X83VG5T30@st13p35im-asmtp001.me.com>; Tue, 23 Aug 2016 12:26:09 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=50 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1608230125 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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... From: Toomas Soome In-reply-to: <20160823121629.GA88122@zxy.spb.ru> Date: Tue, 23 Aug 2016 15:26:04 +0300 Cc: Warner Losh , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers , Toomas Soome , Andriy Gapon Content-transfer-encoding: quoted-printable Message-id: <151A63A8-6444-4E84-80B8-B773C8F661EF@me.com> References: <201608180037.u7I0b77A095653@repo.freebsd.org> <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> <1C479C8A-9F58-425C-8AC2-0A6809F39ACA@me.com> <20160823112940.GW22212@zxy.spb.ru> <20160823121629.GA88122@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 12:26:15 -0000 > On 23. aug 2016, at 15:16, Slawa Olhovchenkov wrote: >=20 > On Tue, Aug 23, 2016 at 03:00:32PM +0300, Toomas Soome wrote: >=20 >>=20 >>> On 23. aug 2016, at 14:29, Slawa Olhovchenkov = 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 wrote: >>>>>=20 >>>>>=20 >>>>>> On 22. aug 2016, at 17:19, Warner Losh wrote: >>>>>>=20 >>>>>> On Mon, Aug 22, 2016 at 3:44 AM, Toomas Soome = 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. >>=20 >> Actually this reduction above is entirely due to -Os, the = =E2=80=94gc-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 =E2=80=94gc-sections with ld. >>=20 >> 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. >=20 > 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? hm, but boot2 is already btx client and btx is setting up the protected = mode. Only zfsboot/gpt[zfs]boot memory copy (boot2 relocator) is working = in segmented real mode, so the gptldr.S and zfsldr.S has to deal with = memory segments to set boot2 up. Or did got you wrong? rgds, toomas