From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C509C4332F for ; Thu, 17 Nov 2022 08:28:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239602AbiKQI2j (ORCPT ); Thu, 17 Nov 2022 03:28:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239536AbiKQI21 (ORCPT ); Thu, 17 Nov 2022 03:28:27 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 138C8729BE for ; Thu, 17 Nov 2022 00:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NNbNOwbcUMHNS/7bdatGU27KOLFjcCDm3+xJi7GtDC0=; b=hC6iPKJY6glbHhdE1Bp6WRha0d mKKJIGEP/FeAZFXUUpITJng8JyaIqt05TwzACd5kfaZvY16QEljkpXzta4UQPAGHZVKc2TH6dzpsz To87fPuqRA6/wX7/x6AUC1baXFt5U/sRlXEmwwmx/nakdSHiUgWC+9rX7u46XyckUspnh36tlIsP1 DBR7jgtp+xmeDzKhbgmJ3JisEDbdyaI+Kdvrs3FwPlMwSqkH8+W2jsu4ZZnngc71AhFKvIXgvVcvj XP+jt9ha75z0rB+tJxeubQNq0A4z11aFRQoXHwGiPnmqNFnKwSm7fDc844P/Xx5OvNrIvr3sT4o/E Vf/RCLTQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovaFj-000nuI-38; Thu, 17 Nov 2022 08:28:07 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 55722300E52; Thu, 17 Nov 2022 09:28:00 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3896C200FC693; Thu, 17 Nov 2022 09:28:00 +0100 (CET) Date: Thu, 17 Nov 2022 09:28:00 +0100 From: Peter Zijlstra To: Ard Biesheuvel Cc: "Jiri Slaby (SUSE)" , linux-kernel@vger.kernel.org, Alexander Potapenko , Alexander Shishkin , Alexei Starovoitov , Alexey Makhalov , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andrii Nakryiko , Andy Lutomirski , Arnaldo Carvalho de Melo , Ben Segall , Borislav Petkov , Daniel Borkmann , Daniel Bristot de Oliveira , Dave Hansen , Dietmar Eggemann , Dmitry Vyukov , Don Zickus , Hao Luo , "H . J . Lu" , "H. Peter Anvin" , Huang Rui , Ingo Molnar , Jan Hubicka , Jason Baron , Jiri Kosina , Jiri Olsa , Joe Lawrence , John Fastabend , Josh Poimboeuf , Juergen Gross , Juri Lelli , KP Singh , Mark Rutland , Martin KaFai Lau , Martin Liska , Masahiro Yamada , Mel Gorman , Miguel Ojeda , Michal Marek , Miroslav Benes , Namhyung Kim , Nick Desaulniers , Oleksandr Tyshchenko , Petr Mladek , "Rafael J. Wysocki" , Richard Biener , Sedat Dilek , Song Liu , Stanislav Fomichev , Stefano Stabellini , Steven Rostedt , Thomas Gleixner , Valentin Schneider , Vincent Guittot , Vincenzo Frascino , Viresh Kumar , VMware PV-Drivers Reviewers , Yonghong Song Subject: Re: [PATCH 00/46] gcc-LTO support for the kernel Message-ID: References: <20221114114344.18650-1-jirislaby@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 14, 2022 at 08:40:50PM +0100, Ard Biesheuvel wrote: > On Mon, 14 Nov 2022 at 12:44, Jiri Slaby (SUSE) wrote: > > > > Hi, > > > > this is the first call for comments (and kbuild complaints) for this > > support of gcc (full) LTO in the kernel. Most of the patches come from > > Andi. Me and Martin rebased them to new kernels and fixed the to-use > > known issues. Also I updated most of the commit logs and reordered the > > patches to groups of patches with similar intent. > > > > The very first patch comes from Alexander and is pending on some x86 > > queue already (I believe). I am attaching it only for completeness. > > Without that, the kernel does not boot (LTO reorders a lot). > > > > In our measurements, the performance differences are negligible. > > > > The kernel is bigger with gcc LTO due to more inlining. > > OK, so if I understand this correctly: > - the performance is the same > - the resulting image is bigger > - we need a whole lot of ugly hacks to placate the linker. > > Pardon my cynicism, but this cover letter does not mention any > advantages of LTO, so what is the point of all of this? Seconded; I really hate all the ugly required for the GCC-LTO 'solution'. There not actually being any benefit just makes it a very simple decision to drop all these patches on the floor.