From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Mon, 30 Oct 2017 13:08:34 +0000 Subject: [PATCH v3] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 In-Reply-To: <20171027163341.57550-1-ndesaulniers@google.com> References: <20171027163341.57550-1-ndesaulniers@google.com> Message-ID: <20171030130834.GK4404@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote: > Upon upgrading to binutils 2.27, we found that our lz4 and gzip > compressed kernel images were significantly larger, resulting is 10ms > boot time regressions. > > As noted by Rahul: > "aarch64 binaries uses RELA relocations, where each relocation entry > includes an addend value. This is similar to x86_64. On x86_64, the > addend values are also stored at the relocation offset for relative > relocations. This is an optimization: in the case where code does not > need to be relocated, the loader can simply skip processing relative > relocations. In binutils-2.25, both bfd and gold linkers did this for > x86_64, but only the gold linker did this for aarch64. The kernel build > here is using the bfd linker, which stored zeroes at the relocation > offsets for relative relocations. Since a set of zeroes compresses > better than a set of non-zero addend values, this behavior was resulting > in much better lz4 compression. > > The bfd linker in binutils-2.27 is now storing the actual addend values > at the relocation offsets. The behavior is now consistent with what it > does for x86_64 and what gold linker does for both architectures. The > change happened in this upstream commit: > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613 > Since a bunch of zeroes got replaced by non-zero addend values, we see > the side effect of lz4 compressed image being a bit bigger. > > To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" > flag can be used: > $ LDFLAGS="--no-apply-dynamic-relocs" make > With this flag, the compressed image size is back to what it was with > binutils-2.25. > > If the kernel is using ASLR, there aren't additional runtime costs to > --no-apply-dynamic-relocs, as the relocations will need to be applied > again anyway after the kernel is relocated to a random address. > > If the kernel is not using ASLR, then presumably the current default > behavior of the linker is better. Since the static linker performed the > dynamic relocs, and the kernel is not moved to a different address at > load time, it can skip applying the relocations all over again." Do you have any numbers booting an uncompressed kernel Image without ASLR to see if skipping the relocs makes a measurable difference there? Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932243AbdJ3NIe (ORCPT ); Mon, 30 Oct 2017 09:08:34 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52224 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751419AbdJ3NId (ORCPT ); Mon, 30 Oct 2017 09:08:33 -0400 Date: Mon, 30 Oct 2017 13:08:34 +0000 From: Will Deacon To: Nick Desaulniers Cc: Ard Biesheuvel , Jiri Kosina , Kees Cook , Gopinath Elanchezhian , Sindhuri Pentyala , Wei Wang , Rahul Chaudhry , Siqi Lin , Stephen Hines , Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 Message-ID: <20171030130834.GK4404@arm.com> References: <20171027163341.57550-1-ndesaulniers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171027163341.57550-1-ndesaulniers@google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote: > Upon upgrading to binutils 2.27, we found that our lz4 and gzip > compressed kernel images were significantly larger, resulting is 10ms > boot time regressions. > > As noted by Rahul: > "aarch64 binaries uses RELA relocations, where each relocation entry > includes an addend value. This is similar to x86_64. On x86_64, the > addend values are also stored at the relocation offset for relative > relocations. This is an optimization: in the case where code does not > need to be relocated, the loader can simply skip processing relative > relocations. In binutils-2.25, both bfd and gold linkers did this for > x86_64, but only the gold linker did this for aarch64. The kernel build > here is using the bfd linker, which stored zeroes at the relocation > offsets for relative relocations. Since a set of zeroes compresses > better than a set of non-zero addend values, this behavior was resulting > in much better lz4 compression. > > The bfd linker in binutils-2.27 is now storing the actual addend values > at the relocation offsets. The behavior is now consistent with what it > does for x86_64 and what gold linker does for both architectures. The > change happened in this upstream commit: > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613 > Since a bunch of zeroes got replaced by non-zero addend values, we see > the side effect of lz4 compressed image being a bit bigger. > > To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" > flag can be used: > $ LDFLAGS="--no-apply-dynamic-relocs" make > With this flag, the compressed image size is back to what it was with > binutils-2.25. > > If the kernel is using ASLR, there aren't additional runtime costs to > --no-apply-dynamic-relocs, as the relocations will need to be applied > again anyway after the kernel is relocated to a random address. > > If the kernel is not using ASLR, then presumably the current default > behavior of the linker is better. Since the static linker performed the > dynamic relocs, and the kernel is not moved to a different address at > load time, it can skip applying the relocations all over again." Do you have any numbers booting an uncompressed kernel Image without ASLR to see if skipping the relocs makes a measurable difference there? Will